The Degraded
Mode Management Framework offers an integrated
set of tools and components.
Design/build
tool. The Ftbuilder permits the specification of application
real-time constraints, different possible application modes
along with related transition conditions.
From this specification, code generation is achieved in order
to instantiate internal control data-bases of run-time components
(ftappmon and ftcontroller) and to provide application model
files.
API.
A specific but reduced API has been defined for manipulating
so called ft-tasks. Three main functions: ft_task_init(),
ft_task_create, ft_task_end(). These ft-tasks are actually
encapsulation of periodic RTLinux tasks. Other functions are
used to init internal data-bases. Besides these specific functions
, application developers can use any RTLinux programming feature.
ftappmon
. The ftappmon component is devoted to global application
handling. It is in charge of overall application setup and
on reconfiguration decisions. It contains information on different
possible application modes and on transition conditions. When
an error is detected and notified by the ftcontroller, the
ftmonitor analyzes the event and issues reconfiguration orders
(stop, awake, switch ft-task behavior) towards the ftcontroller.
ftcontroller
. The ftcontroller is in charge of the direct control of application
threads. It provides error detection (kill or timing error)
and notification (towards ftappmon) and executes reconfiguration
orders at task level.
|
|
Features
 RTLinux
style programming (periodic threads)
 Error
detection (kill, timing errors)
 Application
modes handling
 Transparent
dynamic reconfiguration on detection of abnormal situation.
 Ft-tasks
have several behaviors (normal, degraded) predefined.
Model characteristics
Periodic
tasks
Synchronized
communication model
(one writer/several possible readers. A reader task reads
values emitted during previous period of writer task).
Two
possible behaviors (normal and degraded) for each task are
defined by the developer. These behaviors are implemented
in two alternative threads that are activated or suspended
depending on application mode.
|