in Proc.of The First Workshop on Object-Oriented Real-Time
`Dependable Systems (WORDS'94). Oct. 1994, Dana Point, CA.
`
`The Chimera Methodology: Designing Dynamically Reconfigurable
`Real-Time Software using Port-Based Objects
`
`David B. Stewart* and P. K. Khoslat
`*Dept. of Electrical Engineering and Institute for Advanced Computer Studies
`University of Maryland, College Park, MI) 20742
`
`tDept. of Electrical and Computer Engineering and The Robotics Institute
`Carnegie Mellon University, Pittsburgh, PA 15213
`
`Abstract
`The Chimera Methodology is a new software engineering par-
`adigm which addresses the problem of developing dynami-
`cally reconfigurable and reusable real-time software. The
`foundation of the Chimera methodology is the port-based
`object model of a reusable software component. The model is
`obtained by applying the port-automaton formal computa-
`tional model to object-based design. Global state variable
`table real-time communication is used to integrate port-based
`objects, which eliminates the needfor writing and debugging
`glue code. The Chimera real-tUne operating system provides
`tools to support the software models defined by the Chimera
`methodology, so that real-time software can be executed pre-
`dictably using common real-time scheduling algorithms. A
`hypermedia user intemface has been design edto allow users to
`easily assemble the real-time software components that are
`designed based on the Chimera methodology. Use of the
`methodology can result in a sign (ficant decrease the develop-
`ment time and cost of real-time applications.
`
`1:
`
`Introduction
`
`The Chimera Methodology is a new software engineering
`paradigm for designing and implementing real-time software
`for multi-sensor systems. The Chimera name was used since
`this methodology was a direct result of our work on the Chi-
`mera real-time operating system project [28].
`The methodology addresses the problem of developing
`dynamically reconfigurable component-based real-time soft-
`ware. Transfer and reuse of real-time software is difficult and
`often seemingly impossible due to the incompatibility
`between hardware and systems software at different sites.
`This has meant that new technology developed at one site
`must be reinvented at other sites, if in fact it can be incorpo-
`rated at all. Technology transfer, therefore, has been a very
`expensive endeavor, and the reuse of software from previous
`applications has been virtually non-existent.
`The use of component-based software has been proposed
`to improve software development time by addressing the soft-
`ware reuse and technology transfer issues [26]. For example,
`a user developing a real-time application may need a specific
`software algorithm developed at some other site. Currently,
`The research presented in this paper is supported, in part, by sandia National
`Laboratories, NASA, and the author's institutions. Partial funding for
`D. stewart was provided by the Natural Sciences and Engineering Research
`council of canada (N5ERC) through a waduatc fellowship.
`
`46
`
`users may go to the library or search through the network for
`keywords, then find a book or journal article describing the
`mathematical theory or computer science algorithm. After
`they have printed a copy of the paper, they read the article
`closely, then spend significant time writing, testing, and
`debugging code to implement the algorithm. Once that is
`done, they write more code to integrate the new algorithm into
`their existing system, and perform further testing and debug-
`ging This process can easily take days or weeks of the per-
`son's time for each algorithm needed for their application, and
`thus take many months to complete the programming of an
`entire application.
`The ultimate application programming environment
`should allow for complete software reuse and the ability to
`quickly transfer technology from remote sites. Users who
`need a specific algorithm would search through a global dis-
`tributed software library based on the hypermedia information
`system currently available with the World-Wide Web [32].
`When they find a suitable book or article, they not only get the
`written theory, but they can also follow a link to a reusable
`software module created by the authors. The algorithm would
`already be programmed, fully tested, and debugged. With an
`action as simple as a mouse-click, that software algorithm is
`copied into the user's personal library, and is ready to be used
`in their application. This process would take a few minutes at
`most. The user could then create their application by putting
`together these software building-blocks through the use of a
`graphical user interface. Within hours, a complete application
`could be assembled, as compared to the months that it would
`take to do so using conventional methods.
`This process of assemblmg an application without writing
`or automatically generating any new glue code is called soft-
`ware assembly [26]. In this papel, we describe the Chimera
`methodology, which defines new software models, communi-
`cation protocols, and interfaces for supporting software
`assembly.
`
`2: Related work
`
`There has been significant research in the area of software
`reuse, with three major directions emerging: software synthe-
`sis, interface adaptation, and object desïgn.
`Software synthesis, also known as automatic code genera-
`tion, generally employs artificial intelligence techniques such
`as knowledge bases [1] [3] [24] and expert systems [12] [20]
`to generate the "glue" code for automatically integrating reus-
`
`Page 1 of 8
`
`

`

`able modules. As input, they receive information about the
`software modules, the interface specifications and the target
`application, and as output produce code using both formal
`computation and heuristics. For a truly generic framework,
`however, it is desirable that the integration of software be
`based on the interfaces alone, and not on the semantics of the
`modules or application, as the latter results in the need for
`large knowledge bases. Furthermore, software synthesis only
`allows for statically configuring an application, and usually
`does not support dynamic reconfiguration.
`Interface adaptation involves modil'ing the interfaces of
`software modules based on the other software modules with
`which they must communicate in order to obtain the required
`software integration. In these systems, an interface specifica-
`tion language is used to provide a general wrapper interface
`and to allow meaningful data to be interchanged between the
`modules [11] [14] [16]- This method has led to the notion of a
`software bus, where an underlying server or transport mecha-
`nism adapts to the software module, rather than having the
`software modules adapt to the transport mechanism [4] [19].
`None of these methods have been adapted to real-time sys-
`tems, and there are no clear extensions which would ensure
`that interface adaptation and communication between mod-
`ules can be performed in real-time.
`The Chimera methodology differs from interfacc adapta-
`tion and software synthesis methods of integrating software,
`in that it addresses the actual design of software components,
`rather than just addressing their interfaces.
`Object design is a popular software modelling technique
`which can form the basis for software reuse. An object is a
`software entity which encapsulates data and provides methods
`as the only access to that data Wegner distinguishes between
`two types of object design methodologies: object-based
`object-oriented design
`and
`design (OBD)
`(OOD)
`[7].
`Whereas OBD only defines the encapsulation of data and
`access to that data, OOD is an extension which also defines
`the interrelation and interaction bctween objects. The interre-
`lation of objects in OOD is defined through inheritance using
`the notions of classes, superclasses, and meta-classcs [34]. An
`object-oriented programming language generally performs
`run-time dynamic binding to support this inheritance, and
`objects of different classes communicate with each other
`through messages, where the message invokes the method of
`anothcr object. Such dynamic binding and message passing
`creates unpredictable execution delays, especially in a distrib-
`uted environment, and as a result is not suitable for thc dcsign
`of real-time systems [5]. For example, The Chaos Rcnl-Time
`Operating System [22] was designed to use object-orientcd
`design with real-time systems. Chaos addresses the dynamic
`binding issue by performing static binding during the compi-
`lation and linking stages, thus allowing for predictable cxecu-
`tion of the real-time application. The Chaos system addresses
`the real-time message passing issue by creating a variety of
`specialized messages which are tailored to the target applica-
`tion. As stated by the authors of Chaos in [5]. this, to some
`extent, ruins the objcct model's uniformity and partially
`defeats the purpose of using the object-oriented methodology
`for developing real-time systems.
`
`47
`
`The work presented in this paper is an altemate approach
`which avoids the real-time problems associated with object-
`oriented design, while maintaining the advantages of using
`objects to obtain modular encapsulation, a necessary basis for
`soffivare reusability. lt combines object-based design with the
`port-automaton computational model, as described next, to
`model dynamically reconfigurable real-time software compo-
`nents.
`Streenstrup and Arbib [30] formally defined a concurrent
`process as a port automaton, where an output response is
`computed as a function of an input response. The automaton
`executes asynchronously and independently, and whenever
`input is needed, the most recent data available is obtained.
`The automaton may have intemal states; however all commu-
`nication with other concurrent processes are through the ports.
`The port-automaton theory was first applied to robotics by
`Lyons and Arbib [15], who constructed a special model of
`computation based on it, which was called Robot Schemas.
`The schema used the port-automaton theory to formalize the
`key computational characteristics of robot programming into
`a single mathematical model.
`Arbib and Ehrig extended the work on robot schemas for
`algebraically specifying modular software for distributed sys-
`tems by using port specfications to link modules [2]. The
`specification presented requires that there be exactly one input
`for every output link, and vice versa. The specification does
`not include any notion of objects nor any method to obtain
`reusability of the modules and reconfigurability of a sub-
`system, and they do not speci& the mechanisms required to
`implement their model.
`In our research, these port specifications have been com-
`bined with object-based design in order to create a model for
`reconfigurable real-time software components. The port spec-
`ifications are also extended so that an output port can be
`spanned into multiple inputs and multiple outputs can be
`joined into a single input. In addition, operating system ser-
`vices are provided such that the eornniunication through these
`ports can be performed in real-time and a set of port-based
`objects can be reconfigured dynamically. The next section
`presents the details of the model.
`
`3: Port-Based Objects
`
`A new abstraction for real-time software components that
`applies the port automaton theory to object-based design is the
`port-based object. A port-based object has all the properties
`associated with standard objects. including intemal state, code
`and data encapsulation, and characterization by its methods. It
`also has input, output, and resource ports for real-time com-
`munication. Input and output ports are used for integrating
`objects in the same subsystem, while resource ports are used
`for communication extemal to the subsystem, such as with the
`physical environment, a user interface, or other subsystems.
`A link between two objects is created by connecting an
`output port of one module to a corresponding input port of
`another module, using port names to perform the binding. A
`configuration can be legal only if every input port in the
`system is connected to exactly one output port. A single
`output may be used as input by multiple tasks. In our dia-
`
`Page 2 of 8
`
`

`

`grams, we represent such farming of the output with just a dot
`at the intersection between two links, as shown in Figure 2.
`Both modules A andB require the same inputp, and therefore
`the module C fans the single outputp into two identical out-
`puts, one for each A and B.
`1f two modules have the sanie output ports, then ajoin con-
`nector is required to merge the data into a single unambiguous
`output port, as shown in Figure 3. Thejoin connector's output
`is based on some kind of combining operation, such as a
`weighted average. In this example modules A and B are both
`generating a common outputp. In order for any other module
`to usep as an input, it must only connect to a single outputp.
`The user or software assembly tool (such as Onika [9]) can
`modí' the output port names of modules with the same out-
`puts using the aliasing features provided by the RTOS, such
`that they are two separate, intermediate variables. In our
`example, the output of module A becomes p Ç and the output
`of module B becomes p". Thejoin connector takesp' andp"
`as inputs, and produces a single unambiguous outputp.
`A task is not required to have both input and output ports.
`Some tasks instead receive input from or send output to the
`external environment or to other subsystems, through the
`resource ports. Other tasks may generate data internally or
`receive data from an external subsystem (e.g. trajectory gen-
`erator and vision subsystem interface) and hence not have any
`input ports, orjust gather data (e.g. data logger and graphical
`display interface), and hence have no output ports. Any com-
`munication protocol can be used for the resource ports. This
`allows the hardware dependencies of an application to be
`encapsulated within a single port-based object.
`
`3.1: Object Integration using State Variables
`
`A task set is formed by linking multiple objects together to
`form either an open-loop or closed-loop subsystem. Each
`t.$ port-based * Yí
`t
`
`input ports
`
`object
`
`p p
`
`y
`
`resource ports, for
`communication with sensors,
`actuators, and other subsystems
`Figure 1: Simplified model of a port-based object
`
`Figure 2: Fanning an output into multiple inputs
`*1
`
`I join -
`
`onnectOí
`
`.
`
`object in the subsystem executes as a separate task on one of
`the processors in a multiprocessor environment. An example
`of a fairly simple closed-loop subsystem is the PfD joint con-
`trol of a robot, as shown in Figure 4. It uses three modules: the
`joint position trajectory generator, the PID joint position con-
`troller, and the torque-mode robot interface.
`The port-automaton computational model states that every
`task executes autonomously. At the beginning of every cycle,
`the task obtains the most recent data available from its input
`ports. At the end of the cycle, after performing any necessary
`computations, the task places new data onto its output ports.
`The task is completely unaware of the source and destination
`of the input and output data respectively.
`Autonomous execution is desirable because it allows a task
`to execute independently of other tasks, and therefore does
`not block because another task is using a shared resource.
`Without blocking terms, the analysis and implementation
`complexity of real-time scheduling algorithms such as maxi-
`mum-urgency-first [27] and rate monotonic [23] is minimized.
`The port-automaton model assumes that the most recent
`data is always present at the input ports, which implies that the
`ports are not message queues. With message queues, it is pos-
`sible that no messages are waiting, which occurs when a task
`producing an output is slower than the task requiring the data
`as input. On the other hand, if the task producing output is
`faster, then there is the possibility of multiple messages wait-
`ing at the port, and the next message to be received is not the
`most recent data. Messages create fbrther problems if an
`output must be fanned into multiple inputs. In such cases, a
`message must be replicated, thus making the time to output
`data a function of the number of external tasks. This contra-
`dicts the automaton model where an object is not aware of its
`external environment.
`State variables provide an alternative to messages. A sub-
`system state can be implemented by defining each port as a
`state variable. Writing to an output port then translates into
`updating the state variable, while reading from an input port
`translates into reading the state variable. This method guaran-
`tees that the most recent data is always available as a state
`variable. However, this also introduces a problem of integrity.
`Since a state variable is shared, proper synchronization is
`required to ensure that only complete sets of data are read and
`written. A state variable can be a vector or other complex data
`structure, thus the entire transfer must be performed as a crit-
`ical section. Using semaphores or similar types of synchroni-
`zation violates the port-automaton model because they create
`dependencies between tasks. They introduce blocking terms
`to the real-time scheduling analysis and create the possibi ity
`of priority inversion and deadlocks. We now present our solu-
`
`7 trajectory '\0d br
`generator
`t
`jotnt positiony
`
`bd
`
`Iron user
`
`4
`
`position
`
`t\ontroey
`
`o
`
`brque-modé
`robot
`interface
`
`t
`
`from robot:
`rawjoint
`posh/Ct data
`
`tp robot:
`joint move
`command
`
`Figure 3: Joining multiple outputs into a single input
`
`Figure 4: Example of PIO joint control.
`
`48
`
`Page 3 of 8
`
`

`

`tions for obtaining the required synchronization while main-
`taining an autonomous execution model.
`For single-processor environments, the synchronization
`can be obtained by locking the CPU, assuming that the size of
`a state variable transfer is small. Some may argue that locking
`the CPU may lead to possible missed deadlines or priority
`inversion. This would be true in the ideal case where a CPU
`has no operating system overhead. However, considering the
`practical aspects of real-time computers, it is not unusual that
`a real-time microkernel locks the CPU for up to 100 j.tsec in
`order to perform a system call such as a full context switch
`[31], If the total time that a CPU is locked in order to transfer
`a state variable is less than the worst-case locking of the
`microkcmel due to operating system functions, then there is
`no additional effect on the predictability of the system. Only
`the worst-case execution lime of that task must be increased
`by the transfer time, and that can be accounted for in the
`scheduling analysis.
`In most sensor-based control applications, the volume of
`data is small. For example, for the PID controller in Figure 4,
`each state variable requires ndof transfers, where ndof is the
`number of degrees-of-freedom for the robot. A typical value
`for ndof is less than IO, and therefore the longest CPU locking
`for a state variable would be the time to perform 10 transfers.
`This would typically take less than 5 ksec on a CPU with a
`100 gsec context switch lime, considering that a context
`switch may contain as many as 200 operations for saving and
`restoring registers and updating a process control table.
`One notable exception in which the small volume of data
`assumption does not hold is for images. Vision applications
`can easily require several megabytes of data per second. In
`our model, such applications are implemented as a separate
`subsystem using special image processing hardware, and
`interfaced to the port-based objects using one of the resource
`ports [25]. For a vision subsystem, configurable inter-object
`communication can bc implemented using high-volume data
`streams and synchronized tasks [10]. instead of states and
`asynchronous tasks as dcscribed in this paper. Synchronous
`systems are much more limiting because all tasks must exe-
`cute at the same frequency and dynamic reconfigurability of
`more than one task at a time is usually not possible. However,
`synchronous systems do have an advantage for vision systems
`where a synchronizcd software pipeline is desired. The output
`of such a pipeline is a list of features or specific data points
`within an image. This low-volume output can then be sent to
`a control subsystem which uses the Chimera methodology for
`applications such as active vision [18].
`For multiprocessor environments, we have designed a
`global state variable table mechanism for the intcr-object
`communication [29], since locking only one of the CPUs will
`not provide the necessary atomic execution, and locking all
`the CPUs is not feasible. The mechanism is based on the com-
`bined use of global shared memory and local memory for the
`exchange of data bertveen modules, as shown in Figure 5-The
`global state variable table is stored in the shared memory. The
`variables in this table are a union of the input port and output
`port variables of all the modules that can be configured into
`the system. Tasks corresponding to each control module
`cannot access this table directly. Instead, every task has its
`
`49
`
`own local copy of the table, called the local state variable
`table. Only the variables used by the task are kept up-to-date
`in the local table. Since each task has its own copy of the local
`table, mutually exclusive access to it is not required. There-
`fore, a task can execute autonomously since it never has to
`lock the local table. The key is then to ensure that the local and
`global tables are updated to always contain the most recent
`data, and that the local table is never updated while a task is
`using the table. Details of the global state variable table mech-
`anism are given in [29].
`3.2: Configuration Verification
`In order to ensure that the data required by a port-based
`is always available, a configuration analysis is
`object
`required.
`A legal configuration exists when there is exactly one
`output port for every input port in the task set, and there are
`no two modules which produce the same output. The correct-
`ness of a configuration can be verified analytically using set
`equations, where the elements of the sets are the state vari-
`ables. A configuration is legal only if
`i,j kt ij
`(Yn Y.) = 0, for all i,j such that I
`and
`
`(1)
`
`(2)
`
`Ú }j)
`((
`i
`I
`where
`is a set representing the input variables of module
`f, 15-is a set representing the output variables of module J, and
`k is the number of modules in the configuration.
`As an example, consider the configuration shown in
`Figure 4. Assume that module I is the trajectory generator
`joint position, module 2 is the PfD joint position controller,
`and module 3 is the torque-mode robot inte.'j'ace. Therefore
`= ø. Y = {ee},
`seI' e,}
`2
`= {Tpj , X3 = {Tr} ,andY5 = {8,, 0,}
`From these sets we can easily see that Y,,, Y2, and Y3 do not
`intersect, and hence (1) is satisfied.
`To satisfy (2), the union of the input sets and output sets
`must be taken and compared. We get
`
`= xl U X2 y X3
`
`j Be,,, O @,. m. 'tr}
`
`= Y1 uY,
`
`and
`Y3 = {O Ò. 0, 0,, Tr}
`
`(3)
`
`(4)
`
`Global State Variable Table
`
`local stale
`variable table
`
`lecal state
`variable table
`
`Figure 5: Structure of state variable table mechanism
`for port-based object integration
`
`Page 4 of 8
`
`

`

`Since uX = uY, Equation (2) is also satisfied and thus the
`configuration shown in Figure 4 is legal.
`A task set consisting of port-based objects provides a good
`model for real-time scheduling analysis, because each task
`executes autonomously and independently of other tasks.
`Such characteristics are desirable, as they allow for real-time
`scheduling using algorithms such as maximum-urgency-first
`[27] or rate monotonic [23], without the complexity involved
`in task sets with inter-task dependencies which can result in
`significant blocking, priority-inversion, or deadlock. The
`maximum-urgency-first algorithm is preferred, since it has
`both a performance improvement over rate monotonic, and it
`accounts for the fact that not all tasks have to be hard real-
`time. For example many sensor tasks are soft real-time, in
`that they can tolerate the occasional missed deadline as long
`as the object can extrapolate the data to account for the missed
`cycle.
`Details of the maximum-urgency-first real-time schedul-
`ing algorithm used by the Chimera RTOS, including support
`for hard and soft real-time tasks, aperiodic servers, timing
`failure detection and handling, and automatic task execution
`profiling are given in [25].
`
`3.3: Detailed Port-Based Object Model
`
`In order to ensure autonomous execution of a port-based
`object, the local and global state variable tables must be
`updated regularly, in such a way that the updates never occur
`while a task is executing. To address this issue, we first dis-
`cuss a new programming paradigm for implementing soft-
`ware, then provide a detailed model of a port-based object in
`support of that paradigm.
`Traditionally, software modules are implemented as com-
`plete entities, which can invoke RTOS services though the
`use of system calls. Such an implementation model, however,
`forces each module to be responsible for its own cornmunica-
`tion, synchronization, and integration with other modules.
`Chimera uses an "inside-out" method of programming as
`compared to the traditional methods of developing software.
`Rather than the software modules invoking the RTOS when-
`ever an operating system service is required, the RTOS ser-
`vices are always executing, and they invoke methods of the
`port-based object as needed. Programmers who create soft-
`ware modules only have to define the methods of the port-
`based object; they do not have to write any kind of synchroni-
`zation, communication, or other glue code. As a result, the
`creation of a reusable software component using the Chimera
`methodology is simpler than creating a traditional software
`module. The new programniing paradigm is also highly desir-
`able because the operating system is in total control of every
`task, and as a result enables automatic execution time profil-
`ing for tasks, and allows the operating system to detect timing
`failures and handle them accordingly [25].
`Jn order to demonstrate the principles of the new program-
`ming paradigm, a detailed diagram of the port-based object
`model is presented. Every port-based object in a configuration
`
`50
`
`is a real-time task on one of the processors, and has the struc-
`Pire shown in Figure 7.
`The ellipses show the possible states of the task, which can
`be NOT-CREATED, OFF, ON, or ERROR. A task that is in the OFF
`state has been created, meaning that a context for the task
`exists, but that the task is in a suspended state waiting for a
`signal. The ON state represents a task that is ready to execute
`its next cycle, either in response to a timer wakeup signal for
`a periodic task, or the arrival of an event in the case of an ape-
`riodic task. The ERROR state is for tasks that have encountered
`unrecoverable errors during their execution.
`The transition between states occurs as a result of signals
`sent by a subsystem interface to the RTOS. The subsystem
`interface signals can come from a user through a command-
`line or graphical interface, from an external subsystem, or
`from another task in the same subsystem in the case of an
`embedded system. These signals are shown in Figure 7 as
`solid bars.
`The methods of an object are invoked by the RTOS in
`response to the signals from the subsystem interface, and form
`part of the state transitions. The methods are shown as rectan-
`gular boxes. Each object has each of the following special
`methods: mit, on, cycle, off kill, error, clear; remit and sync.
`The mit and on components are for a two-step initialization.
`The cycle component executes once for each cycle of a peri-
`odic task, or once for each event to be processed by an aped-
`odìc server. The off and kill components are for a two-step
`termination. The error and clear components are for auto-
`matic and manual recovery from errors respectively. The
`remit component is used for dynamic reconfiguration. The
`sync component is used by aperiodic servers to receive events
`through a port-based object's resource ports. More details on
`each of these methods is given below.
`Before and after each method of a port-based object is exe-
`cuted, a transfer is made between the local and global tables.
`This ensures that a method always uses the most up-to-date
`data, and that new data is immediately placed into the global
`table. These state variable table transfers are shown in
`Figure 7 as oval boxes.
`
`Ç
`
`Xm
`
`"m
`
`,
`
`Jacobian '
`multiply c
`
`I
`
`ndof
`
`dh
`V
`'V
`rroard '
`kinematics! I
`,j.i"R,,iacobiani 0
`ndof
`
`tresotved"
`k,...............
`
`acceleration
`control er1
`
`inverse
`acceleration __a
`\,,mappinq j
`
`ndol
`
`db
`
`robot
`interface
`
`. time
`
`inverse
`integrator7 - dynamics
`
`Y' -,
`
`tr
`
`f
`
`'-
`
`_,
`
`'
`
`-
`
`'
`
`'6-00F'
`trackball
`x-velocity I X
`t
`
`from trackball:
`raw reference
`data
`
`to robot:
`from robot:
`rw lout raw torque
`postren datacommand
`Figure 6: Example of module integration:
`Cartesian teleoperation
`
`Page 5 of 8
`
`

`

`A port-based object can have two kinds of input: constant
`input that needs to be read in only once during initialization
`(in-canst) and variable input which must he read in at thc
`beginning of each cycle (in-var) for periodic tasks, or at the
`start of event processing for aperiodic tasks. Similarly, a task
`can have output constants (out-const) or output variables (out-
`var). Both the constants and variables are transferred through
`the global state variable table. State constants are used for
`developed generic software and reconfigurable device driv-
`ers, as described in detail in [25 J.
`A two-step initialization and termination is used to support
`dynamic reconfigurability. High-overhead initialization and
`termination code is performed during the lidi and kill methods
`respectively, whereas tasks can be activated and deactivated
`quickly using the on and off methods. The on method is used
`to update the objects internal state to reflect the current sub-
`system state. The off method is used in cases where the sub-
`system state must be modified when a task terminates in order
`to ensure the integrity of the system even after the task stops
`executing.
`The cycle component is executed every time the task
`receives a wakeup signal while the task is in the ow state. For
`ÑoT'\
`REATE9J
`-
`
`on any error
`ader task receives
`on' signal
`
`ut-comEs
`
`Ou t- C On S
`A
`reilE
`
`>in -vaN
`
`>ou t-va rs
`
`(>in-consI
`
`(out.ats>)
`
`on
`+
`(oui-vais>)
`
`leim
`
`4.
`errol
`
`t
`
`clear if SBSERROR
`returned
`
`ERROR
`
`dea
`
`SBS CONTINUE
`returned
`
`ou L-va rs
`A
`c cre
`
`vars/
`= wake4
`
`Aperiodic,
`
`external
`signai
`
`Legend
`
`Ostate of task
`
`call cneciOed
`method or oojedt
`
`______
`
`block until soecilied
`event occurS
`
`(
`
`)
`>xxx: copy from global into
`local slate variable table
`xxx>: copy Iron local into
`global state vanabte table
`
`Figure 7: Detailed model of a port-based object.
`
`51
`
`periodic tasks, the wakeup signal comes from the RTOS timer,
`whereas for aperiodic tasks, the wakeup signal can result from
`an incoming message or other asynchronous signaling mech-
`anism supported by the underlying operating system. The
`sync method is used by thc aperiodic servers to receive events,
`and to block if no events are pending.
`The Chimera methodology uses a global error handling
`paradigm to detect and handle faults in the system [25]. An
`error signal is generated whenever an error is encountered.
`The signal can be caught by either a user-defined or system-
`defined error handler. By default, an error generated during
`initialization prevents the creation of the task, and immedi-
`ately calls the kill component which can free any resources
`that had been allocated before the error occurred. If au error
`occurs after a task is initialized, then the error component is
`called. The purpose of the en-or component is to either
`attempt to clear the error, or to perform appropriate alternate
`handling, such as a gracefUl degradation or shutdown of the
`system. If for any reason the task is unable to recover from an
`error, the task becomes suspended in the ERROR state, and a
`message sent to the subsystem interface indicating that oper-
`ator intervention is required. After the problem is fixed, the
`operator sends a clear signal, at which time the clear compo-
`nent is called. The clear method can do any checks to ensure
`the problem has indeed been fixed. If everything is fine to pro-
`ceed, then the task returns to the OFF state, and is ready to
`receive anon signal. If the error has not been corrected, then
`the task rcmains in the ERROR state. The Chimera methodol-
`ogy currently defines the fault detection and handling, but
`does not yet define methods of incorporating fault tolerance.
`The port-based object model allows tasks to be configured
`based on the input constants. Such configuration is performed
`during the task's ini