Development framework approach to heterogeneous system design for control systems

Control Eng. Practice, Vol. 4, No. 2, pp. 229-238, 1996 Copyright © 1996 Elsevier Science Ltd Printed in Great Britain. All rights reserved 0967-0661196 $15.00 + 0.00

Pergamon PII:S0967-0661 (95)00230-8

DEVELOPMENT FRAMEWORK APPROACH TO HETEROGENEOUS SYSTEM DESIGN FOR CONTROL SYSTEMS M.J. Baxter*, J.M. Bass*, A.R. Browne*, M.S. Hajji*, M.O. Tokhi*, P.R. Croll** and P.J. Fleming* *Department of Automatic Control and Systems Engineering, The University of She[field, Mappin Street, Sheffield, UK (M. J.Baxter @sheffield.ac, uk) **Department of Computer Science, The University of Sheffield, Mappin Street, Sheffield, UK

(ReceivedMarch 1995; infinal form November 1995) Abstract: An integrated environment of software development tools, known as the Development Framework, which automates the design process for complex realtime embedded control systems, is introduced. The approach favoured here is to maximise the use of commercially available tools that are well understood by current industrial practitioners. Where necessary, new tools are introduced both in unifying the automated method and for supporting specialist functions. Introduced here is one such specialist example: support for the design of heterogeneous systems. This paper details the work on heterogeneity, and demonstrates how the essential properties of the Development Framework have been preserved. Thus, the Framework presents a unified methodology and an open system architecture. Finally, what should be learnt from this for building future techniques and tools for complex real-time control systems is discussed.

Keywords: Parallel computers, heterogeneous architectures, design systems, scheduling and software tools.

1. INTRODUCTION

the allocation of task priorities within hard real-time systems.

1.1. Complex Real-time Systems

Many control engineering applications have safety considerations, being either safety-critical or simply safety-related, whereby any unnecessary failure is regarded as totally unacceptable or the consequences of failure too expensive. There is concern that the stringent software reliability requirements needed for safety systems may, in practice, be unattainable (Littlewood and Strigini, 1993). To ensure that specified reliability levels are achieved, issues such as performance gains, component costs, hardware diversity, voting and reconfiguration must be assessed at an early stage of the design process. Failure to do so will cause late modifications to the design and implementation, possibly even hacked, after requirements capture and any system-wide hazard analysis has been undertaken. This will result in unpredictable behaviour.

Modern computer control applications are placing ever-increasing demands on the development process. The production of high-quality, dependable realtime software within acceptable cost constraints is a non-trivial task (Stankovic, 1988). As systems become more multi-functional, the task of specifying, designing and implementing a complete system is becoming more time-consuming and error-prone. This has been compounded by the introduction of multi-processing, through either distributed or parallel processing, necessary to meet the current performance, reliability and functionality requirements. Current standard software engineering techniques do not adequately support a full development cycle for such systems (Birkinshaw, et al., 1994; Jelly and Gorton, 1994). The designer is faced with a number of conflicting requirements which are often impossible to isolate due to their strong interdependencies. For example, there are difficulties in the management of deadlines, in guaranteeing predictability, and in

It should be recognised though, that complex control systems do have evolving requirements and must, therefore, be developed using modern software engi229

230

M.J. Baxter et al.

neering methods that are designed to facilitate this. Computer-aided software engineering (CASE) tools offer improved management of complexity and provide documentation support leading to reduced development time. Such benefits have led to their increasing application in the commercial control engineering environment. Tools alone do not provide a dependable development environment. The integration of existing methods and the development of new methods, together with the appropriate tool support, are required to facilitate the engineering of complex control applications. It is the belief of the authors that these techniques and tools must provide for the modelling and explicit management of concurrency, incorporate the heuristics of good design practice, include formal mathematical models and yet provide interfaces familiar to the real-time design engineer.

plementation. Support tools enable analysis and refinement of the distributed system under development.

1.2 Development Framework Overview

1.2.2. Design Phase The Development Framework automatically generates a design from the specification. This is represented using a standard software engineering dataflow notation (Hatley and Pirbhai, 1987). Automatic translation reduces the possibility of introducing errors when compared to a manual translation procedure. A Development Framework translation tool is used to reconstruct the control system diagram from the Simulink file, and produce dataflow and data structure diagrams in the Software through Pictures (StP) CASE environment (IDE, 1992). An equivalent dataflow diagram (DFD) is created for each Simulink diagram within a model, and a data structure diagram is created for every connection between blocks in each Simulink diagram.

1.2.1. Specification Phase System specifications are produced in the Development Framework using a graphical tool which supports methodologies specific to the control engineering field. Application-specific system specifications allow designers to use methodologies which are both familiar to them and optimal for the application. In the Specification Phase, see Fig. 1, the control engineer refines behavioural requirements by simulation and analysis using the Simulink computer-aided control system design package (Mathworks, 1992). Once the simulated behaviour is satisfactory, the specification must be translated into a design.

The Development Framework is a set of computeraided engineering tools that provides a highly automated translation from a specification to an implementation, for further details see (Bass, et al., 1994) and (Browne, et al., 1994). The Development Framework is divided into three phases (namely, specification, design and implementation) representing the different stages of development as shown in Fig. 1. The specification is in a popular, graphical control engineering notation, typically representing a system with stringent reliability requirements and hard realtime constraints. The translation to an executable form is made via a software engineering model of the system. All the source code produced using the Development Framework is either automatically generated or comes from existing reusable libraries. Thus, no hand coding is necessary at the time of im-

The Framework draws on the communicating sequential processes (CSP) paradigm (Hoare, 1985). The message-passing approach of CSP provides an

Functional Requirement Refinement Temporal Requirement Refinement

~l

Specification Phase

Functional Simulation

- Popular Notation -

Simulation

- Graphical specification

Fig. 1 Development Framework Overview.

Design v

Implementation Phase

Temporal Simulation

- Documentation

- Automatic code generation

- Dependability Improvement

- Software reuse

- Deadlock avoidance

231

Heterogeneous System Design elegant platform for the development of such distributed systems. Dataflow diagrams are used to model concurrent processes and message-passing channels. CSP-based processes and communication channels are, thus, conveniently modelled using CASE tools.

neering of heterogeneous systems, as can be seen in Fig, 2. In this section these specialised tools are discussed and demonstrated on several case-study algorithms.

2.1. Case Studies of Flight Control Laws 1.2.3. Implementation Phase

The Development Framework translates the Software Design Phase description into the source files required to create a complete, executable version of the system. The source files are created from a reusable, user extensible, library of source code templates and an automatically generated communication harness. The source code required to map processes to processors is also automatically generated. Since code generation is the only part of the Development Framework that is implementation-specific, all that needs to be changed for the design to be implemented using different types of parallel platform is the code generator. The portability of the design is kept high as source code is produced at a very late stage in the system development. Currently, the primary code-generator within the Development Framework produces source code in the language "C" for the Virtuoso real-time kernel (ISI, 1993) executing on a network of Inmos Transputers. Transputers provide a convenient platform for the CSP model and have found numerous applications in real-time control (Irwin and Fleming, 1992). The Virtuoso kernel includes a flexible, reconfigurable, synchronous message-passing system and a ratemonotonic scheduler which makes it particularly suitable for use in the Framework. 2. HETEROGENEOUS DEVELOPMENT FRAMEWORK PHASES

The Development Framework has been augmented with a number of further tools to permit the engi-

Transformation Toolbox

~

2.1.1. Application algorithms Three linear flight control laws are used to demonstrate the use of the heterogeneous tools. The first is the versatile autopilot (VAP) flight control law shown in Fig. 3. This is a relatively simple (12 state) cross-coupled multipleinput multiple-output control law, and exhibits several parallel paths that have potential for exploitation by parallelism. The second algorithm is shown in Fig. 4. This is a translation of the VAP algorithm into the independent path form. The third algorithm is the 11-state Tumip helicopter flight control law. This is shown in Fig. 6. The initial representation of each of these algorithms is in transfer function form. 2.1.2. Hardware and Software Support An architecture described as 'heterogeneous' contains a network of processing elements of differing types and performance. This is in contrast to the more conventional uni-processor and homogeneous architectures that only employ identical processing elements. The inherent nature of a heterogeneous architecture can provide two significant advantages over other solutions: performance and fault-tolerance (through hardware diversity). The real-time performance advantage, which is the motivation for this research into heterogeneity, can be realised by forging a close match between the algorithms' computation and communication requirements and the underlying hardware resources. It is believed that heterogeneous architectures can match the computational needs of many demanding classes of real-time applications that cannot be easily solved by other solutions.

Mapping Tool StandardCompiler, LinkerandConfigurer

Simulink Specification

Framework Translation Tool

Code Generator

I

I

I

I

I

I

Specification

~I

Design

I

Phase

I

Phase

I

I I

Fig. 2 Development Framework Tools.

I I

Implementation Phase

232

MJ. Baxter et al. yap Edit Options S_imulationStyle Code

[Z}--d, hb

,

G2

I

A?

Gh-

I

-i s o s I

;r~a.U-'Ic-~.~ ~

A4

Gh.

A5

G8

G7~-%

Is+1.666F

I

G10

,[] ua

Gll

vd

Au

Fig. 3 Application Algorithms: VAP flight control law. Various types of processors can be used to construct a heterogeneous architecture. Here, particular interest lies in a multiprocessor architecture with point-topoint communication links, that can support a CSP paradigm (Hoare, 1985). This is a well-understood parallel-processing software approach and is considered favourable for this research. The system is developed for control and digital signal processing

(DSP) applications with real-time performance being of prime importance. The system currently in use incorporates an Inmos T8 transputer and several Texas Instruments' TMS320C40 DSPs, as can be seen in Fig. 7 (Texas, 1991). Obviously these processors are electrically incompatible, and both software and hardware interfacing is required for integration. A homogeneous language approach where the source vapip

I~ I-~

"t

File Edit Options Simulation Style Code

I~] q

#

I ZZ.5s+Z3.5 s+10 Transfer Fcnl

I

hb

8.5s5 +3621 s4+6Z.8Zs 3 +48.89s z +8.431 s+0.Z77 +7.5s4 +19.88s8 +ZS.74s z +13.83s+Z.776 I Transfer FcnZ

[Z]---* h

Sum

80.164 +Zl 0.7s4 +535.5s'-.3+618.Z~ +351.6s+1.67 S5 +1 Z.595 +57.38s4 +1ZS.Z~ +18Z.1 ~ +69.41 s , l 3.88 Transfer Fcn3

I~ ua

It,

-4.915s-0.Z45 s+1.67

~1~ vd

Transfer Fcn4

Fig. 4 Application Algorithms: VAP flight control law algorithmic tansformation into the independent path form.

Heterogeneous System Design

formance potential. For example, the tools can be used to tune a variety of characteristics of an algorithm, such as granularity, regularity, degree of vectorism or parallelism. This section will discuss the algorithmic transformations that have been used with the case-study algorithms, and their merits.

vapippar

Edit O__ptionsSimulation Style Code

q•

ZZ,Ss.Z3.5 [ s+10 / Transfer Fcnl s+1.98807 J T ~ I

qlT

-0A08669s-4.33153 +1.67066s*0.037809 I Z.Z5107 L ransfer FcnZ.3

L.I -3, o84 I

l

--

Transfer FcnZ.4

233

38 °o, 1

+

+

nd

Sum

The transformations are performed within the application domain, and thus the nature of the transformations is application-dependent. For example, in the control-systems domain, transforms to decompose high-order transfer functions into several lower-order transfer functions can be used to tune the granularity of the blocks (Garcia-Nocetti and Fleming, 1992). The system developer can tune the algorithm, guided by both optimisation and performance analysis tools, to yield maximum performance. A number of transformation types are provided. These include translations between the transfer function and state-space representations, the parallelisation of complex highorder blocks into groups of simpler parallel blocks and independent path extraction.

Transfer Fcn3.1 .~

2.2.2. Algorithm Transformation Results As an example of this technique, the granularity of the blocks of the VAP algorithm will be tuned. Algorithm granularity is simply the ratio of the computation requirements to the communication requirements.

-12.7768 Transfer fcn3.Z

_~

11.8831

rl S'Z000" Transfer Fcn3.3

.~

7.364,s+18.Z238 s~ .1.66836s+0.8299Z9 Transfer Fcn3.4

Transfer Fcn3.5

Transfer Fcn4

vd

!!

Fig. 5 Application Algorithms: VAP flight control law algorithmic tansformation into the parallelised independent path form. code can be compiled for any processor is used, thus reducing the complexity of mixed languages. The 3L Parallel C compilers are used here for both processor types (3L Ltd, 1991, 1994). This is effective because it reduces the complexity of writing architecture-dependent library modules.

2.2. Specification Phase Extensions 2.2.1. Transformation toolbox The transformation toolbox (TT) augments Simulink and permits the mathematical recasting of the structure of an algorithm in an attempt to make it more appropriate for the underlying hardware, whilst preserving its functionality (Baxter et al, 1994). This is an important development phase, since a heterogeneous implementation relies heavily on a close match between the algorithm and hardware to realise the full per-

Granularity is a software engineering metric and therefore cannot be determined directly from the application domain algorithm. A value of granularity can, however, be determined from the code templates that represent these blocks. The computational requirements are assumed to be dominated by floatingpoint operations. The communication requirements are simply the number of words that are to be communicated to or from neighbouring blocks. Thus, either by inspection of the code or by simple automated profiling, the granularity can be determined for each block. The transformation to the independent path realisation, as shown in Fig. 4.for the VAP, can be used to simplify a control algorithm, provided that numerical integrity is preserved. When Fig. 4 is compared with Fig. 3 it can be seen that the structure of the algorithm has been significantly simplified. This is a useful starting point at which to develop the algorithm further. Also note in Fig. 4 that only four transfer function blocks appear, two of which are high-order expressions. It is shown in Table 1 that the evaluation of these expressions involves significant computation compared with the lower-order expressions. For example, Transfer Fcn2 requires 44 FLOPs per cycle of the algorithm, and two words of independent communication. The task granularity of the four transfer functions is found to vary between 5 and 23, see Table 1. In an attempt to reduce the granularity of these higher-order expressions, a second transformation was applied to each path. The paths were parallelised

234

M.J. Baxter et al. Table 1 Granularitv calculations for the indenendent oath renresentation of the VAP control law. Block Name

FLOPs

Comms (words

Task Granularity

T.Fcn. 1

10

2

5

T.Fcn. 2

44

2

22

T. Fcn. 3

46

2

23

T. Fcn. 4

10

2

5

and first-and second-order expressions obtained, as shown in Fig. 5. This resulted in an overall increase in the number of blocks, but a significant reduction in the granularity size, see Table 2. For a homogeneous system, equivalent size granularities, matched to the processor, would be required. However, the findings of Table 1 are more appropriate for a heterogeneous system consisting of two processors with hardware granularities of -5 and -20 respectively. However, for Table 2 the granularities are lower and would require processors of a similar granularity.

HOST

Fig. 7 The Topology of the Experimental Heterogeneous Architecture.

2.3. System Design Phase Extensions

ping' refers to the allocation of the tasks that represent the parallelised algorithm onto the processors in the architecture. Mapping is a critical stage of a heterogeneous implementation, as a badly mapped algorithm is unlikely to be well matched to the hardware, and this can have a significant impact on the realtime performance. However, mapping has been found to be computationally hard (NP-complete) (Shirazi et al., 1990). Therefore, to obtain an efficient mapping a heuristic approach must be used.

2.3.1. Mapping tools and results A key phase of any parallel implementation is mapping. Here, 'map-

A significant amount of consideration has been given to the development of mapping heuristics for homoTurnip

File EeliI O~otions Simulation Style

Outport

:b ,El

Outpodl

Inpo~4

"1

I

Inpo~5

[]

Inport6 Inpo~7

Fig. 6 The Turnip Helicopter Flight Control Law.

.D OutporlZ

Heterogeneous System Design Table 2 Granularitv calculations for the narallelised indenendent oath representation of the VAP control law. Block Name

FLOPs

Comms (words)

Task Granularity

T. Fcn 1

10

2

5

T. Fcn 2. I

10

2

5

T. Fcn 2.2

14

2

7

T. Fcn 2.3

6

2

3

T. Fcn 2.4

6

2

3

T. Fcn 3.1

6

2

3

T. Fcn 3.2

6

2

3

T. Fcn 3.3

6

2

3

T. Fcn 3.4

14

2

7

T. Fcn 3.5

6

2

3

T. F c n 4

10

2

5

geneous architectures by numerous researchers (Thoeni, 1994). Unfortunately the development of mapping heuristics that take account of the special characteristics of heterogeneous architectures is still in its infancy. Few research groups have addressed the issues of heterogeneity in mapping (Tripathi and Menasce, 1992; Menasce, et al., 1991a,b; Baxter, et al., 1995). However, it is clear that to minimise the run-time overheads of an algorithm, the mapping must be performed off-line (static mapping). This reduces the performance penalty that a dynamic mapping policy would introduce. This approach is particularly appropriate when the tasks composing the algorithm are not required to be dynamically reallocated, or the task precedence changed during runtime. The design tools harness two distinct heterogeneous mapping algorithms. The cost of a mapping is determined using either a simulation model of the execution, or directly from the implementation of that mapping. The mapping algorithm combinations are as follows:•

The Modified Menasce (MM) heuristic approach using a simulation model,

•

A genetic algorithm (GA) using a simulation model, and

• A GA using the hardware-in-the-loop. The simulation model relies upon previously measured execution times of each task on each processor and measures of communication performance, and this information is used with the DFD to determine

235 Table 3 Algorithm cycle time~,

Algorithm

VAP flight control law

Independent path VAP flight control law

Turnip helicopter flight control law

Mapper

Simulated Measured Cycle Time Cycle Time (~s) (,as)

Modified Menasce

290.93

354.00

Genetic Algorithm

113.62

281.00

GA and Hardware

240.76

239.00

Modified Menasce

117.27

128,00

Genetic Algorithm

117.27

127.00

GA and Hardware

117.27

120.00

Modified Menasce

230.08

299.00

Genetic Algorithm

111.00

195.00

GA and Hardware

327.87

168.00

the cycle-time of the complete algorithm. The alternative mapping policies are discussed below. Modified Menasce Approach The MM heuristic constructs a mapping in a single pass and does not perform any iterative optimisation of the mapping. The performance of this mapper has previously been explored through simulation, and as such was ripe for experimentation on a real application and architecture (Menasce, et al., 1991a,b). However, the initial implementation of the algorithm was found to perform poorly, as it did not take account of the communication overheads. The algorithm was subsequently modified to include the implications of communication. Genetic Algorithm Approach GAs capture Darwin's evolution theory (Goldberg, 1989). A population of solutions is evolved by successive and repeated breeding, where each new generation captures the characteristics of the best preceding solutions. In addition, solutions are periodically mutated to introduce new genetic material which broadens the search. GAs are robust and particularly appropriate when the shape of the searchspace is not well understood. This makes GAs an appropriate optimisation method for the heterogeneous

236

M.J. Baxter et al.

mapping problem. This mapping approach can be used either with the execution model or with the hardware within the optimisation loop (Baxter, et al., 1995).

2.3.2. Mapping Results The application algorithms were mapped using all three approaches. A summary of the results is shown in Table 3. The first observation to be made is that, for these application algorithms, the GA approaches both significantly outperform the MM approach in terms of identifying mappings that result in lower measured execution times. Furthermore, the GA that exploits the hardware in the optimisation loop resulted in an 18% increase in performance for the more complex algorithms, when compared to the GA that used the model. The independent path VAP algorithm has only a few tasks, and should not be challenging to the mapping algorithms. However, the GA with the hardware approach still determined a slightly faster result than the other algorithms. Moreover, after inspection of the mappings it was found that this required only 3 of the total 4 processors that were available, clearly demonstrating that the communication overheads can drive tasks together. A disparity occurs between the simulated execution time and the measured execution time. This suggests that the model should be developed further. The execution times of the two versions of the VAP flight control law emphasise the need for tuning the algorithm's structure to the hardware. The simple transformation to an independent path form has resulted in a more than halving of the execution time. To further visualise the effectiveness of the mapping algorithms consider Fig. 8. This represents the cycletime distribution for a sample of random mappings (2000) of the VAP flight control law. Here, the most common cycle-time interval is 500-520MS. The vertiCycle time distribution for a sample of random mappings 350 i

i

250

~ 200 15o z

lOO

I

I

100

200

300 400 500 Algorithm Cycle Time (uS)

It is important to note that the MM and the GA with the execution model both determined solutions relatively quickly, instantaneously for the MM, and up to an hour for the GA. However, for the GA with the hardware the compilation of every mapping incurred a massive increase in time for the GA to converge. Typically, for the more complex application algorithms this mapping algorithm was run for about 18 hours using a Sun LX SPARCstation, and even then it was not clear whether further improvement was possible.

2.4. Implementation Phase Extensions 2.4.1. Heterogeneous Code Generation The DFD is an intermediate representation, between the initial algorithm and an architecture-dependent executable form. The code generator is the tool used to translate the algorithm from the mapped DFD to an executable code. It is recognised that algorithms from a particular application domain are often built from a small number of computational block types. This characteristic has been exploited by the code generator. A library of reusable code modules has been designed, that represent the most common building blocks of the application domain (e.g., transfer functions and state-space equations) and can easily be extended to allow other classes of algorithms to be implemented. The heterogeneous code generator assembles the library modules into complete source code files ready for compilation, with due consideration of differences between programming languages. Here, the code generator creates files suitable for the 3L Parallel C compilers, as is used for both processor types. The code generator also generates the configuration files and 'make' files for automating the compilation phase.

i ~GA + r

300

cal dotted lines represent the best mappings achieved by each of the mapping algorithms. The MM approach does not appear to be performing well, when compared to the GA approaches. In particular, the GA with the hardware approach has determined a mapping that results in a two-fold increase in performance when compared to the most common interval of the random search. Comparing the best cycletimes determined by the mapping algorithms with the results of the random search give a useful indication of how good the mappings are. However, a measure of how far the best mappings are from the optimal would also be valuable. Unfortunately, this is difficult to estimate.

600

1-]1--]__, 700

Fig. 8 Cycle-time distribution for a sample of random mappings for the VAP algorithm.

800

2.4.2. Performance Analysis The final stage of the development cycle is performance analysis. This determines whether an implementation fulfils its specification. The performance metrics are diverse. However, real-time performance metrics may include measures of throughput, latency and reliability. If the implementation does not achieve the performance required or the architecture is considered too costly,

237

Heterogeneous System Design then the developer can return to any of the previous development stages in an attempt to tune either the algorithm or the hardware configuration to realise the maximum performance and/or minimum cost. A performance analysis tool is currently being implemented. 3. F U T U R E D E V E L O P M E N T S A N D CONCLUSIONS

The Development Framework can provide a powerful environment for automatic code generation of complex real-time control software. To achieve this it requires an open environment to permit analysis and optimisation at the appropriate stages of development. The transformation toolbox demonstrates how algorithms may be manipulated in order to realise an appropriate matching of software to hardware. The integration of the toolbox into the Framework environment has been discussed. The efficacy of several mapping approaches has been examined. For the algorithms described here, the GA approach outperformed the MM algorithm. The integration of the hardware into the optimisation loop of the GA resulted in significant improvements. Future development tools must not only allow open access to the objects they possess, but must also allow integration of new techniques through modifications. That is, the tools should be sufficiently open to permit new rules and additional functionality through coding. The more recent versions of StP impose some password restrictions on tool modification to protect their copyright. This reduces the application area of certain tools, preventing the experience gained from their use in industrial applications from being further exploited. Considering the complexities involved in designing control systems it would be foolhardy to rely entirely on any single black-box tool approach to automatic code generation. Even if safety is not an issue, some analysis of behaviour and timing consistencies should be undertaken. Comprehensive testing of complex systems is not always possible, post mortem analysis can be intractable since implemented code can be too complex to unravel, and debugging in order to find deadlock conditions, for example, is inadequate. Therefore, analysis should be undertaken in the design phases where the necessary reduction in complexities can be achieved, e.g. reduction in the state space. The case study of the heterogeneous system identified that access to the many design parameters and performance attributes was needed to achieve appropriate automated analysis. Tools that provide impressive, easy-to-use interfaces may appear to help ease the handling of complexity. If this incurs a loss of integration capabilities then it can leave the design engineers dependent on one method or tool for each task in hand. No single method or tool can yet cope with the complexities of real-time control systems, and no substitute for the

experience of good design heuristics can be made in this evolving and important field. 4. A C K N O W L E D G E M E N T S The authors gratefully acknowledge the support of UK EPSRC (under contract numbers GR/Jl1843, GR/H79078 and GR/K64310) and Intelligent Systems International (suppliers of Virtuoso) for this work. 5. R E F E R E N C E S

3L Ltd. (1991) "Parallel C User Guide for the INMOS Transputer". 3L Ltd. (1994) "Parallel C User Guide for the Texas Instruments TMS320C40". Bass, J. M., A. R. Browne, M. S. Hajji, D. G. Marriott, P. R. Croll and P. J. Fleming, (1994) "Automating the Development of Distributed Control Software", IEEE Parallel and Distrbuted Technology, Vol. 2, No. 4, Winter 1994, pp. 9-19. Baxter, M.J., M. O. Tokhi and P. J. Fleming (1994) "Parallelising Algorithms to Exploit Heterogeneous Architectures for Real-time Control Systems", Proceedings of the lEE Control '94 Conference, Vol. 2, pp 1266-1271. Baxter, M.J., M. O. Tokhi and P. J. Fleming (1995) "Mapping Real-time Control Algorithms onto Heterogeneous Architectures", IFAC Workshop on Algorithms and Architectures for Real-time Control. Birkinshaw, C., P. R. Croll, D. Marriott and P. A. Nixon (1994) "Engineering Safety-Related Parallel Systems", Information and Software Technology, Vol. 36, No. 7, 1994, pp:449-456. Browne, A. R., J. M. Bass, P. R. Croll and P. J. Fleming (1994) "A Prototype Framework of Design Tools for Computer-Aided Control Engineering", Joint IEEE/IFAC Symp. on Computer Aided Control System Design, 1994, pp. 369-74. Garcia-Nocetti, D.F. and P. J. Fleming (1992) "Parallel Processing in Digital Control", Springer-Verlag. Goldberg, D.E. (1989) "Genetic Algorithms in Search, Optimisation and Machine Learning", Addison-Wesley. Hatley, D. J. and I. Pirbhai. (1987) "Strategies for Real-Time System Specification", A., Dorset House Publishing Co. Inc., 1987. Hoare, C. A. R. (1985) "Communicating Sequential Processes", Prentice Hall, Englewood Cliffs, New Jersey, U. S. IDE. (1992). "Software Through Pictures User's Guide", Interactive Development Environments, San Francisco, U.S.

238

M.J. Baxter et al.

Irwin, G. W. and P. J. Fleming (eds). (1992) "Transputers in Real-Time Control", Research Studies Press, 1992. ISI (1993) "Virtuoso User Manual", Intelligent Systems International, Linden, Belgium.

Dynamic Processor Scheduling Disiplines in Heterogeneous Parallel Architectures", University of Maryland at College Park, Technical Report UMIACS TR-91-162 and CS TR-2807.

Jelly, I. E. and I. Gorton (1994) "Software Engineering for Parallel Systems" in Information and Software Technology, July 1994, Butterworth-Heinemann.

Shirazi, B., M. Wang and G. Pathak (1990) "Analysis and Evaluation of Heuristic Methods for Static Task Scheduling", Journal of Parallel and Distributed Computing, Vol. 10, pp222-232.

Littlewood, B. and L. Strigini. (1993) "Validation of Ultrahigh Dependability for Software Based Systems", Communications of the ACM, Vol. 36, No. 11, pp. 69-80, November 1993.

Stankovic, J.A. (1988) "Misconceptions about real-time systems - a serious problem for next generation systems", IEEE Computer, October, 1988, pp.10-19

Mathworks (1992) "Simulink User's Guide", The Mathworks Inc., Natick, MA., U.S., 1992.

Texas (1991)"TMS320C4x User's Guide", Texas Instruments, Inc. (1991).

Menasce, D.A., S.C. da Silva Porto and S.K. Tripathi (1991a) Static Heuristic Processor Assignment in Heterogeneous Multiprocessors, University of Maryland at College Park, Technical Report UMIACS TR-91-131 and CS TR-2765

Thoeni, U.A. (1994) Programming Real-time Multicomputers for Signal Processing, Prentice Hall International.

Menasce, D.A., D. Saha, S.C. da Silva Porto, V.A.F. Almeida and S.K. Tripathi (1991b) "Static and

Tripathi, S.K. and D.A. Menasce (1992) "Scheduling Issues in Heterogeneous Multiprocessor Systems", Transputers '92, pp. 1-16.