Automating the development of distributed control software - IEEE ...

Automating the Development of Distributed Control Software Julian M. Bass, Adrian R. Browne, Mohamed 5. Hajji, Derek G. Marriott, Peter R. Croll and Peter J. Fleming University of Sheffield

n e Development Fra mework tra nslates application-specific system specifications into parallel, hard real-time implementations, using methods that are bothfamiliar to developers and optimal for the application.

Winter 1994

R

eal-time control systems must operate within stringent physical and operational constraints. But as such systems become more complex, the task of specifymg, designing, and implementing them is becoming more time-consuming and errorprone. In hard real-time systems, for example, there are difficulties in managing deadlines, guaranteeing predictability, and allocating task priorities. W e can obtain improved function and greater flexibilityby implementing real-time distributed control subsystems in software, but the safety-critical nature of many control-engineering applications has led to concern that sufficiently stringent software-reliability requirements may be unattainable.' To ensure reliability, mechanisms such as checkpointing, voting, and reconfiguration must be assessed early in the design process. However, complex control systems typically have incomplete and unstable requirements; modifications can be expected during design and after commissioning. Achieving response-time requirements, for example, may result in failure to meet mass, volume, or power consumption constraints. Designers faced with such a conflict may relax functional behavior requirements slightly - by relaxing result accuracy, for example allowing the use of a simpler algorithm that requires less processing power. Resolving such conflicts requires experience and intuition. If designers could model, simulate, and analyze the system before implementing it, they would better understand the trade-offs between conflicting constraints and would have evidence that their design decisions will result in the best compromises.

1063-655?/94/$4.00 0 1994 IEEE

9

Functional requirement refinement Temporal requirement refinement I

I

engineering

Executable

and then views the resulting simulation of the new behavioral properties. T h e framework can then produce the Popular notation Documentation Automatic code new design, documentation, temporal Simulation Dependability generation Graphical specification improvement Software reuse model, and source code with a high Deadlock avoidance degree of automation. This process is far less costly than malung the same Specification Software design Implementation changes to a hand-constructed system. Figure 1. D e v e l o p m e n t F r a m e w o r k overview. In addition, automatic translation and code reuse can reduce the number of errors when compared to manual translation. Our Development Framework approach applies CASE T h e Development Framework offers a number of tools - as well as several new tools - to the developother benefits: ment of distributed systems, so designers can concentrate T h e system specification is in a familiar, applicationon the control-engineeringaspects of their systems? The oriented notation. approach addresses three development phases: specificaThe software design tools are useful regardless of the tion, software design, and implementation (see Figure 1). application-specificnotation used, and can integrate In the specification phase, the control e n p e e r refines subsystems specified in different notations. behavioral requirements through simulation and analyDuring software design, system characteristics such sis, thereby verifying that the system meets its functionas timeliness and dependability can be modeled, al requirements prior to implementation. Once the simassessed, and optimized. ulated behavior is satisfactory, the specified behavior is The CASE tools provide documentation support that translated into a design. Finally, our tools produce source aids communication between members of the design code, either by automatically generating it or by drawing team and fulfillment of contractual obligations. it from a library. No hand coding is needed during impleSafe state analysis is supported through automatically mentation, and the automatic translation frees the develgenerated temporal models. oper from the need for specialized knowledge of deadlock analysis, process-to-processor mapping, fault In the rest of this article, we describe the three phastolerance, process synchronization,and so on. The source es of the Development Framework approach, and the code that maps processes to processors is also automatinew and existing tools we apply during each phase. We cally generated. then demonstrate our approach using an example of a The Development Framework allows the rapid prolinearized roll-pitch-yaw autopilot and airframe model. totyping of control system software by providing a highly automated translation from an application-specific Specification specification to a distributed implementation that can execute on a parallel platform using a real-time kernel. Many computer-aided-engineering packages represent Since code generation is the only part of the Developsystem structure as diagrams that are more accessible ment Framework that is implementation-specific, only and natural than written language or mathematics. T h e the code generator has to be changed for the design to be Development Framework uses the Simulink tool for implemented using different parallel platforms. Also, the computer-aided control-system design because the tool framework's open architecture ensures that the designer uses a graphical notation that is widely used by concan intervene to optimize or analyze the implementation. The Development Framework does not directly suptrol engineers; accommodatesboth continuous and discrete elements; port the maintenance phase of a project's lifecycle; enables the specification of different sampling rates reverse engineering, for example, is beyond its scope. However, the translation tools do provide a number of within the same system; supports the hierarchical decomposition of diagrams, benefits. For example, to make functional modifications to the system requirements, the control engineer refines enabling representation of complex control systems; allows the creation of new symbols; and a graphcal specification to reflect the new requirements, I

I

Functional simulation

10

Temporal simulation

IEEE Parallel & Distributed Technology

Clustering and

uses a file format suitable for parsing by the Development Framework's software tools.

-

Petri net model

Standard compileri linker, and configurer

Simulink graphical specification

-

Executable

Source code template library S i r n d d supports modeling and simulation during control law design and Replication toolprovides a well-documented mechanism Specification Software design Implementation for specifying control systems. However, its transfer-function block-diagram Figure 2. Development Framework tools. Bold type indicates new tools notation does not represent many of the developed for the Development Framework. features central to parallel and distributed systems. As a result, the Development Framework's software design enables the system to generate and manipulate diaphase applies deadlock analysis, a degree of temporal analygrams with minimal intervention by the developer; sis, mapping, and fault-tolerant mechanisms, as required. has a flexible and extendible storage structure for specific information about each object within the sysSoflware design tem (each diagram, process, dataflow, and so on); and allows access to all object and diagram data (for code In the software design phase, a Development Framework generation, for example). translation tool constructs a control system diagram from the Simulink file and produces dataflow and data structure diagrams in the Software through Pictures CASE When converted into the software-engineering notaenvironment (see Figure 2 ) . An equivalent dataflow diation, the system design is functionally equivalent to the gram is created for each Simulink diagram within a original specification in the application-specific notamodel, and a data structure diagram is created for every tion. However, this design generally is not an efficient connection between blocks in each Simulink diagram. implementation, and it may not meet some non-funcAll functional blocks w i h the Simulink diagram (gams tional requirements, such as timeliness and reliability and transfer functions, for example) are converted into constraints. Therefore, the framework's software design equivalent process symbols. Withln a dataflow diagram, a phase includes three tools that analyze and optimize the Simulink block that maps to an U 0 device (such as a sensystem to meet these constraints while maintaining the sor or actuator) is converted to a process symbol, which correct functionality. Changes are limited to those contains the details for the U 0 device driver, and a symaffecting non-functional criteria, such as reliability and bol representing an external. Each Simullnk inpodoutefficiency of implementation. T h e framework performs port symbol is converted into an off-page connector, these optimizations with minimal intervention. allowing processes and their decompositions to be linked. Thus, the CASE tool maintains a complete description of CLUSTERING TOOL the application system, allowing the analysis, implemenAutomatic code generation in the Development Frametation, and documentation of the proposed design. work is based on finctional decomposition:Specifications T h e Development Framework draws on the CSP use block diagram components that map directly to (communicating sequential processes) message-passing equivalent code modules. a p p r ~ a c hwhich ,~ uses dataflow diagrams to model conUnfortunately, this approach results in many smallcurrent processes and message-passing channels. W e grained tasks (often containing fewer than SO lines of adopted Software through Pictures for modeling CSPhigh-level source code). T h e current block diagram based processes and communication channels because it components represent low-level functional behavior, such as integrators and gains. These tasks use messagesupports the well-known Yourdon software-engipassing to communicate data from one to another, but neering methodology with Hatley/Pirbhai real-time such fine-grained message-passing often results in inefextensions;+ ficient code and poor performance. offers a menu system flexible enough to allow the Our clustering tool overcomes this problem by addition of new tools; replacing selected message-passing communications

I

Winter 1994

I

11

with simple procedure calls. The tool performs the conversions during code generation with minimal intervention by the designer. It first searches for dataflow diagram annotations stored in the CASE tool. (Currently, the clustering annotations are manually inserted.) It then clusters all processes that lie hierarchically below an annotated task; that is, these process are accessed by function calls rather than by message-passing. Finally, the tool maps the processes in a cluster to a given node during later stages of code generation. Of course, this conversion of message-passing to procedure calls can only be applied to tasks mapped onto the same node.

The code templates can be reused both w i h the same design and from one design to another, thus helping to control software-development costs. (The cost of designing, implementing, and documenting low-level modules can be spread over more than one system.) T h e investment in verification of code templates (whether using testing, formal methods, or both) can also be spread over a large number of designs. The generation of application source code is simplified.

Functionally, these source code templates mimic the behavior of elements in Simulink's block diagram library. Providing template library compoEach building block REPLICA~ON TOOL nents that are equivalent to the simin the source code T h e Development Framework ulation tool components simplifies template library addresses the stringent reliability the translation process. is tested to requirements of real-time control T h e Development Framework applications by using redundant subestablish correct makes system analysis tractable by systems and a voter. The framework's imposing a formalism -a set of rules functionality, and replication tool automatically replithat the source code templates must to obtain best- and cates tasks or groups of tasks, allowing obey. Based on the CSP model, this worst-case those with high reliability requireformalism requires all communication execution times. ments to be mapped onto separate to take place either at the beginning These times are nodes. Such mapping of replicated and/or end of each piece of code in the software modules helps the system to template library. T h e communicathen used in tolerate hardware faults, and voting tions are synchronous and blocking. temporal analysis. helps to mask errors emanating from The system design (the dataflow diaa minority of the redundant subsystems. gram) only makes sense when the templates follow these T h e replication tool can be used prior to code genrules. Thus, a process in a dataflow diagram represents eration. Like the clustering tool, it searches first for a "building block" of source code obtained from the temdataflow diagram annotations, and then for all processplate library, while an arc represents a synchronous, es that lie hierarchically below an annotated task. T h e blocking message-passing communication. tool then replicates these tasks; that is, it extends the T h e building blocks in the source code template dataflow diagram with copies of the annotated subsyslibrary are individually tested to establish correct functem. T h e replication tool also inserts the additional tionality, and to obtain best- and worst-case execution communication paths required and selects a voting algotimes for each template. These times are then used in rithm from the template library. temporal analysis (explained in the next subsection) to show that deadlines will be met, that the system will not SOURCE CODE TEMPLATE LIBRARY enter unsafe states, and that the system is deadlock-free. The Development Framework uses templates from which The investment in verification can also be atomized over application code modules are derived. The templates have several designs, because the building blocks can be been collected into a library for ease of access and control. reused. Thus, we can consider 100% path testing and There are several advantages to this approach: formal verification where costs might otherwise be prohibitive for a single system. The library can be used to provide a one-to-one mapCode templates have the additional advantage of simping between simulation components and functional plifymg code generation. The approach is well suited to code modules. generating code within restricted application domains. A formalism imposed upon the code templates supT h e number of templates required is modest, since ports temporal analysis and predictable system design. embedded control applications do not require large num12

IEEE Parallel & Distributed Technology

bers of different low-level functional elements. For exampetri nets instead use an occurrence graph, since the ple, summing elements, gains, and transfer functions tokens are now complex data objects. In a colored petri net, an occurrence graph can be genoccur frequently in classical controller designs. It is the interconnection of these low-level functional modules erated that makes deadlock detection trivial. Livelock that varies from design to design. The difficulty in impleoccurs when a transition can fire but is prevented from menting such systems is often due to the large number doing so by the firing of other transitions. This happens when multiple transitions contend for a token, a situation of instantiations of these few functional module classes. often encountered in models of parallel systems in which Temporal analysis at the design stage is possible a place represents a resource and the transitions reprebecause the source code building blocks have a simple structure that ensures deterministic execution times and sent different processes trying to access the resource. predictable behavior when executed For hard real-time applications, and __ especially for safety-critical systems, on selected hardware architectures. It livelock for some specified duration is not necessary to generate source can be as catastrophc as deadlock. T o code until satisfactory functional and Assuming that all show the absence of livelock, the temporal behavior has been obtained. the code templates reachability tree must show that for a Constraints are placed upon the abide by the given state, there is always potential source code in templates - loops formalism, the to progress to a new state (that is, a must be bounded at compile time, for given transition will eventually fire Development example. So far these coding restricgiven an infinite number of tions have not posed implementation Framework can enablings). This requires temporal difficulties. translate the analysis in addition to state analysis. system design into COLORED PETRI NET GENERATION The colored pem net representation a hierarchical TOOL lets the developer add time inscripcolored petri net tions. T h e developer can acquire staAssuming that all the code templates for formal analysis. abide by the formalism, a Developtistical timing estimates through simment Framework tool can translate ulation, and calculate, in conjunction with an occurrence graph, best- or the system design into a hierarchical worst-case timing. (The timings ignore any processor colowd petri net. Petri nets are a formal method for scheduling effects, whch must be modeled separately.) designing and analyzing parallel systemss They can be represented as a graph, thus hiding the underlying mathematics and making the models more easily understood Implementation by the designer. Unfortunately, early forms of petri net Our Development Framework prototype automatically are cumbersome for modeling systems with a large numgenerates code from the system design stored in the Softber of states, adding complexity to the subsequent analyware through Pictures CASE tool. The functional source sis. Colored petri nets handle this complexity by using code modules originate from the template library, and tokens of different colors to represent different types of each code module corresponds to an element in the complex data objects (equivalent to data types in tradiSimulink diagram of the control system. For example, tional programming languages). Introducing hierarchian integrator block in the Simulink model requires an cal decomposition further aids the developer by allowintegrator code module in the library. ing the design and analysis to be broken into manageable T h e code generator produces all the C code required subnets. T h e Development Framework uses a hierarto compile, link, and execute the system on a network of chical colored petri net tool called DesigdCPN. Inmos Transputers. Transputers are a convenient platIn a colored petri net, transition guards (Boolean form for the CSP model and have found numerous expressions on transitions) enable or disable transitions, applications in real-time control.6 T h e code generator depending on the data flowing down the arcs. Functions produces source and configuration files ready for comon the arcs can create or destroy tokens flowing from pilation with the Virtuoso real-time kernel. T h e Virtuone place to another. Standard petri nets can be anaoso kernel includes a flexible, reconfigurable, synchrolyzed using a reachability tree, which shows how the net’s state alters as each transition fires, while colored nous message-passing system and a rate-monotonic Winter 1994

13

i All of these processes execute iteratively. In each iteration, the process receives data from all the input dataflows, executes the functional code (uansfer function or gain, for example), and sends data to all the output dataflows.

I Load data I

--Y3

Figure 3. Top-level Simulink diagram of the example model (a), and decomposed Simulink diagram of the roll channel (b).

scheduler that make it particularly suitable for our framework. (Complex control systems require a combination of time-bounded, time-limited, and background proce~ses.~ Some processes have strict deadlines, while others have widely varying priorities.) For each process in the system, two source code files are produced: an application code file and a harness code file. T h e application code file contains the code for the functional part of the process (such as transfer-function or gain), and is taken from the library of code templates. T h e harness file contains code that manages interprocess communication, and is automatically generated to match the needs of the process. In addition to these two basic types of code files, a number of others are also generated to handle platform configuration and task mapping. These allow the Development Framework to support different hardware architectures and provide simple task-management facilities. As mentioned earlier, the Development Framework's formalism represents each nondecomposed process symbol in a system's dataflow diagrams as a separate process in the implementation. T h e formalism limits our prototype to purely periodic systems. No concept of aperiodic tasks or events has been developed yet. All interprocess communication is strictly synchronous. 14

A suitable library module for a process is chosen automatically based on the number and type of input and output dataflows and the type of routine (such as gain) that is required. This information is all stored within the Software through Pictures CASE system when the control system design is converted into dataflow diagrams. A start-up routine, defined within the library module, allows variables, sensors, and actuators, for example, to be initialized.

An example T o evaluate the application of the Development Framework to a control system design, we selected the IEEE CACSD Technical Committee Second Benchmark Problem.s T h e benchmark consists of three models representing a generic, linearized, continuous-time, rollyaw-pitch autopilot and airframe simulation. T h e models vary in complexity, from a simple uncoupled single-channel model with 13 state variables, to an intermediate coupled low-frequency three-channel model with 42 state variables, to a detailed high-frequency model with 73 state variables. T h e Development Framework implementation of the detailed model, without clustering, contains about 10,500 lines of generated source code. About 5,200 lines are obtained from the template library. Implementations using clustering contain less source code, and obtain a higher proportion of code from the library. This model is distributed with Simulink as a tutorial example, and the framework's translation tool parses it into the system design phase without modification. T h e Simulink solution to the benchmark problem has been publisheds and so can be used as a reference system. In particular, the Simulink model provides step-response data that we used to check the functional behavior of IEEE Parallel & Distributed Technology

I f

the implemented system. Although the benchmark problem is not a realworld design, the detailed model is a mature design.

~

..5

\

SPECIFICATION Figure 3a shows the standard Simulink top-level diagram for the benchmark problem. T h e notation is a transferfunction block diagram, which is popular among control engineers. T h e Autopilot and Arframe blocks can be decomposed to reveal more detailed functional block diagrams of each subsystem. T h e arcs U1, U2, and U3 represent the three autopilot outputs (pitch, roll, and yaw channels). There are also seven feedback paths from the airframe to the autopilot. T h e blocks Ncp and Ncy represent step signal inputs that are used to test the model and check that its accuracy conforms to previously published results. Figure 3b shows the decomposed Simulink diagram for the autopilot roll channel. The inport (Y3) and outport (U2) connect signals to other diagrams in the model. The system is composed of functional modules such as gain blocks (K9, for example), transfer function blocks (G15), sum blocks (Suml) and further subsystems (G7/G11).

From . Airframe to Autopilot-num-4 ,','

!

From Airframe to AutopilotLnum~S

(a)

From I Demux 41 to 612

From Demux 4 From K11 GI6

-

AutopilotiRAutoC

( ) ( 2:bop

FromK9

2211+ ) h m R A u t o C

AutopilotiRAutoC to G7 G8 AutopiIoffRAutoC=D ' 'L 67 G8

Figure 4. Top-level (a) and decomposed (b) dataflow diagrams corresponding t o the Simulink diagrams in Figure 3.

SOFTWARE DESIGN

Our translation tool created the dataflow diagrams in Figure 4 from the Simulink diagrams in Figure 3. T h e structure of the top-level diagram in Figure 4a is similar to that of the Simulink diagram in Figure 3a: T h e three output dataflows and seven feedback dataflows connect processes 2 and 3 (the autopilot and airframe processes). As in the Simulink diagram, the processes can be decomposed to reveal more detailed dataflow diagrams of each subsystem. Figure 4b shows the decomposed autopilot roll channel. T h e translation tool has translated the gain block K9 in Figure 3 b into process 2.2.10 in Figure 4b, and the transfer function GI 5 into process 2.2.8. Where no further decomposition is needed (such as when translating gain, sum, and transfer-function blocks), the translation tool generates process specifiWinter 1994

cations within the CASE tool (Software through Pictures). Where subsystems are translated (such as when translating block G7/G11 in Figure 3b into process 2.2.13 in Figure 4b) the translation tool does not create process specifications. Such processes must be decomposable to reveal the subsystem dataflow diagram and do not require a process specification. Figures 3 and 4 show the close structural relationship between the specification (transfer-function block diagram) and design (dataflow diagram) obtained by using functional decomposition. However, some aspects of the two notations are not identical. T h e Simulink notation allows branches in communication paths, while the dataflow diagram reflects the underlying CSP approach, which allows only point-to-point communication. Thus, the Development Framework's 15

A comparison of design tool approaches T h e Development Framework provides problem-oriented support tools that emphasize finding satisfactory compromises between conflicting physical constraints. In contrast, software synthesis’ is more solution-oriented, and emphasizes selecting from a rich set of general-purpose software algorithms, data structures, and architectures. In software synthesis, requirements must be rigorously developed to guide code generation. Formal notations are often used to ensure that requirements are strictly defined. T h i s approach helps ensure that implementations satisfy requirements, but it provides only limited support for developing the requirements specification. T h e Development Framework acknowledges that requirements are often a compromise between conflicting desirable system properties (reliability and performance, for example). T h e ControlHz and MetaH3 toolsets take a similar approach. ControlH is a fourth-generation language with a graphical front end designed to support the modeling and specification of control algorithms. MetaH allows the specification of connections between different software components, like those developed using ControlH. It also supports the specification of a system’s nonfunctional attributes, such as realtime scheduling. M e t a H can support both fault-tolerant mechanisms and implementation on a parallel platform. Simulink is an extension of Matlab and is widely used for dynamic system simulation. Simulink’s C code generator automatically generates executable real-time C code from Simulink block diagrams for continuous, discrete-time, and hybrid systems. Matlab, Simulink, and the C code generator provide a rich

set of functionality for control system design, analysis, and implementation. Matrix-X also provides control system design, modeling, simulation, and implementation tools for the optimization of process and system performance. Matrix-X is an interactive matrix manipulation environment with a comprehensive graphics facility and an expandable function library. Furthermore, Matrix-X is the entry-level tool for a product family that includes comprehensive system analysis, nonlinear simulation, automatic real-time code generation, and prototyping. Table A contrasts these three approaches with the Development Framework. All four approaches offer reusable code modules and applicationoriented graphical specifications. T h e Simulink code generator, however, does not directly support parallel processing or fault tolerance, and code portability may lead to low efficiency for a given hardware platform. ll/latrixX uses a shared-memory approach to allow a distributed system implementation, but does not directly support the inclusion of fault-tolerant mechanisms.

References 1. D. Setliff,E. Kant, and T. Cain, “Practical Software Synthesis,” IEEE Sopware, Vol. IO, No. 3, May 1993, pp. 6-10. 2 . M .Englehart and ,M. Jackson, “ControlH: A Fourth-Generation Language for Real-Time GN&C Applications,” Pror. IEEEIIFACJoint Symp. Computer-Aided Control System Design,

IEEE Press, Piscataway, N.J., 1994, pp. 261-270. 3 . C. Vestal, “Integrating Control and Software Views in a Cace/CASE Toolset,” P7,oc. IEEE/IFACJoint S p p . Computer-Aided Control System Design,

IEEE Press, Piscataway, N.J., 1994, pp. 353-358.

Table A. Comparison of selected design tool approaches.

SIMULINKCOOE GENERATOR

MATRIX-X CONTROLHDEVELOPMENT METAH FRAMEWORK TOOLS

Reusable module library

J

J

J

J

Graphical specification

J

J

J

J

J

J

J

J

J

ParalleVdistributed architecture Fault-tolerance support Standard softwareengineering notation

J

Formal analysis support ~________~

translation tool must insert communication modules to replace joints on arcs in Simulink diagrams. For example, the tool has inserted a demultiplexor (process 2.2.1) into the dataflow diagram in Figure 4b. This module is required to distribute information entering the dataflow diagram to the three subsequent processes(2.2.2,2.2.13,and2.2.14). 16

T h e ControlWMetaH tools offer some level of support for fault tolerance. T h e Development Framework also supports two areas not addressed by the other approaches: the standard software-engineering notation and tools for formal analysis. Also, the framework uses a commercial CASE tool (Software through Pictures) to provide a complete description of the system under development. T h e CASE tool provides document-preparation facilities and consistency checking.

Clustering tool Table 1 shows execution times for a number of configurations using message-passing or procedure calls. In column 1, the autopilot and airframe models have been consolidated into a single task, and all communication is performed via procedure calls; the results are the fastest single-node execution times we have obtained. In column IEEE Parallel f4 Distributed Technology

Table 1. Performance of message-passing versus procedure calls. ~

ALL

MESSAGE-PASSING

MESSAGE-PASSING

(1 NODE)

(2 NODES)

(1 NODE)

0.9 ms. 2.1 ms 3.0 ms.

4.5 ms. 9.2 ms. 8.9 ms.

5.9 ms. 11.6 ms. 12.5 ms.

~

2, the autopilot and airframe models form two tasks, each mapped to a different node and communicating with each other by message-passing. In column 3, the autopilot and airframe are mapped to the same node but (unlike in column 1) use message-passing for communication. In column 4, all communication is performed by messagepassing. These results show that we can improve performance up to SO times by converting all communications in the intermediate model to procedure calls. Also, columns 2 and 3 show that for the detailed model, mapping the autopilot onto a separate node improves performance by nearly 1.Stimes.

Replication tool

ALL

AUTOPILOT~AIRFRAME

PROCEDURE CALLS

Simple model Intermediate model Detailed model ~~

AUTOPILOT/AIRFRAME

~~

MESSAGE-PASSING

27.5 ms. (48 tasks) 111.1 ms. (164 tasks) 129.0 ms. (175 tasks) ~~

~

~

-

Autopilot replicates Data demultiDlexors

Autopilot

Y4

Figure 5. Conversion of t h e a u t o p i l o t from a simplex system to a fivem o d u l a r r e d u n d a n t system.

Table 2. Execution t i m e s of simplex, 3-MR, a n d 5-MR systems.

Figure S shows a simplified diagram of the additional components required SIMPLEX(2 NOOES) 3-MR (4 NODES) 5-MR (6 NOOES) to convert the autopilot into a five13.5 ms 19.0 ms. 4.5 ms. Simple model modular redundant system: multi41.6 ms. 50.1 ms. ms. 9.2 Intermediate model plexors, additional communication 34.6 ms. 50.1 ms. 8.9 ms. Detailed model channels, and a voter. Once the replication has been performed, the designer can annotate the voter in the dataflow diagram. This annotation can be used to select a specific voting algoPetri net translation tool rithm and specify a threshold, if required by the voter. Figure 6 shows the petri net model of the detailed examFour centralized voting algorithmsare available: majorple system. T h e shaded boxes represent models of the ity, plurality, median, and weighted a ~ e r a g eW . ~e have clusters used in the Development Framework formalimplemented two versions of each -one for use in mpleism. For this example, four types of cluster must be modmodular redundant (3 -MR) systems and the other for use eled: source, sink, standard, and initial firing. in five-modular redundant (5-MR) configurations. Table 2 shows execution times of the simplex, 3-MR, IMPLEMENTATION and S-MR configurations. T h e degraded execution W e tested the implementations to demonstrate correct times in the redundant systems indicate one of the costs numerical behavior compared with published simulaof higher reliability. W e can partially explain this pertion results. W e found each configuration to be deadformance loss by the presence of the voter, but most of lock-free for the tested data sets. W e produced all the the delay is due to the naive mapping of replicates to a code using the tools described here, without any manpipeline processor configuration. The pipeline necessiual editing. In fact, only two menu selections were tates through-routing of messages from each replicate required to generate the unclustered simplex modules to the voter. Configuring the network with point-tofrom the Simulink specifications. All the tested configpoint communication, where possible, is likely to urations compiled successfully, without modification. improve execution times; we are now studymg this. ~~~

Winter 1994

~~

~~~~

~~

17

’ Y

T

he existing tools in the Development ramework provide all the components required to translate from Simulink specifications to code. More complex systems - such as those that involve mode switching from one control law to another - will require further tool support. T h e software design phase is the most suitable point at which to integrate subsystems. T h s integration is also essential for systems where different design teams specify subsystems using different application-specific notations. T h e Development Framework‘s open architecture allows the addition of tools to address problems at different stages of the design lifecycle. W e are now developing performance monitoring tools, and ANSI C and Occam code generators, and we also plan alternative simulation, mapping, and scheduling tools. W e will allow further reliability enhancement by adding selected distributed voting algorithms and mechanisms to support checkpointing. W e also hope to have additional tools for the graphical specification of time constraints, human interfaces, and data-processing activities. Finally, we intend to add control and timing specifications to allow the framework to handle aperiodic as well as periodic events.

ACKNOWIEDGMENTS We gratefully acknowledge the helpful suggestions received from the anonymous reviewers and the editorial staff, and the support of both UK EPSRC (under contract number GRRl79078) and Intelligent Systems International (suppliers ofvirtuoso) for this work. W e thank Derryck Lamprey and Ashiq Al Moosani for their contribution toward the petri net translation tool. W e also thank Andrew Chipperfield for assistance with the parsing of Simulink data files, and Les Woolliscroft for his comments on an earlier draft.

REFERENCES

Figure 6. Petri net diagram of the example system.

18

1. B Littlewood and L. Strigini, “Validation of Ultrahigh Dependabilityfor Sohare-Based Systems,” Comm. ACM, Vol. 36, No. 11, Nov. 1993, pp. 69-80. 2. A.R. Browne et al., “A Prototype Framework of Design Tools for Computer-Aided Control Engineering,” Proc. yoint IEEE/IFAC Symp. Computer-Aided ControlSystemDerign, IEEE Press, Piscataway, N.J., 1994, pp. 369-374. 3. C.A.R. Hoare, Communrcatrng Sequential Processes, Prentice-Hall, Englewood Cliffs, N.J., 1985. 4. D J . Hatley and LA. Pirbhai, Swategiesfbr Real-Time System Specification, Dorset House, New York, 1987. 5. J.L. Peterson, Petri N e t Theoly and the Modeliizg ofSysremr, Prentice-Hall, Englewood Cliffs, N J . , 1Y81. 6. G.V\’. Irwin and P.J. Fleming, eds., Transputenin Real-Time Control,John Wiley & Sons, New York, 1992. 7 . A.W.P. Bakers and J. van Amerongen, “Transputer-Based Control of Mechatronic Systems,” Proc. I?th IFAC World Congress, Pergamon, Oxford, England, 1991. 8. M. Rimer, D. Frederick, and C. Huang, “Solutions ofthe Second Benchmark Conuol Problem,” IEEE Conrvol Systems, Vol. 10, No. 5, Aug. 1990, pp. 33-39. 9. P.R. Lorczak, A.K. Caglayan, and D.E. Eckhardt, “ ATheoretical Investigation of Generalized Voters,” Digest of Papers 19th IEEE Symp. FaultTolerant Computing Synemr, IEEE Computer Society Press, Los Alamitos, Calif., 1989, pp. 444451.

IEEE Parallel & Distributed Technology

Julian M. Bass is the research associate coordi-

nahng the Development Framework project at the Uruversity of Sheffield. HISresearchlnterests include computer-aided control-system design, computer-aided software engmeenng, and faulttolerant systems. Bass is cochair of the session on Dependable Distributed Systems at the Third Euromicro Workshop on Parallel and Distributed Processing. Before receiving his degree in computer systems engneering from the University of Wales in 1990, he had nearly 10 years of experience ln the electronics and computer industry. He is a member of the IEEE Computer Society and ACM. Adrian R. Browne is a research student in the Department of Automatic Control and Systems Enpeering at the University of Sheffield.HIS research interestsincludereal-time systems, multiprocessor scheduling strategies, and code generation. He received his MSc in control systems from the University of Sheffieldin 1992,and his BSc in mathematicswith computer science from the University of Southampton in 1989.

Mohamed S. Hajji is a research student in the Department of Automatic Control and Systems Engineering at the University of Sheffield. His research interests include performance monitoring and the temporal behavior of real-time distributed software. He received his MSc in control systemsfrom the University of Sheffield in 1993,and his postgraduate degree (DES) and BSc in computer science from the Higher Institute of Applied Science and Technology.

Derek G. Marriott is a PhD student at the University of Sheffield. His researchinteresa include fault-tolerantcomputing,parallel computers,and colored petri nets, and he has produced several papers on engineering safety-related software systems. He received his BSc in computer science from the University of Sheffield in 1992.

Peter R. Croll is a lecturer in computer science at the University of Sheffield, and a member of the department’s Parallel Processing Research Group. He is also a director of the Sheffield Centre for Advanced Computing, a technology-transfer initiative. His research interests include the application of parallel processing to the design of dependable real-time embedded systems. He received a degree in computer science in 1978, worked in industry as an electronics engineer, and received his PhD in computer science from the University of Sheffield in 1990.He is a member of the British Computer Society and is a Chartered Engmeer.

Winter 1994

PeterJ. Fleming ISa professor of lndustrial systems and control in the Department of AutomahC Control and Systems Engneering at the Uruversity of Sheffield. He is also head of department and director of the Rolls-RoyceUniversity Technology Centre for Control and Systems Engmeering His research interesa include the application of parallel processing to real-time control and instrumentation, computer-aided control-system design, and ophmizahon methods He has produced more than 150 publicahOnS in these areas, including four books, and he is chair of the IFAC Technical Committee on Algonthms and Architectures for Real-Time Control. Fleming was premously a professor of computer systemsengneering at the University of Wales, an associate professor at Syracuse Uruversity, and a research ScienhSt at NASA Langley.

Readers can contact the authors at the Deparhnent of Automahc Control and Systems Engineering, Unweryity of Sheffield, PO Box 600, Mappin St., Sheffield, S1 4DU, England; Internet j.bass@sheffield ac uk