- Email: [email protected]
Automated code generation of embedded real-time systems
North-Holland Microprocessingand Microprogramming 24 (1988) 51-56
51
AUTOMATED CODE GENERATION OF EMBEDDED REAL-TIME SYSTEMS Antti Auer * Pekka Kemppainen ** Ari Okkonen * Veikko Seppgnen * * Technical Research Centre of Finland Computer Technology Laboratory P.O.Box 181, SF-90101 Oulu FINLAND ** Kone Corp. Research Centre P.O.Box 6, SF-05801 Hyvink/i~i FINLAND
A code generator is presented, ltproducesfull tasks for real-time systems from a structured data/control flow description. The work is based on ideas behind the RT-SA/SD methodology and program transformation paradigm. The code generator is written in Prolog. It is now capable of producing programs in PL/M-86 language for realistic applications and Petri nets for dynamic analysis. The resulting code has been found effective. The dynamic analysis has proven its ability to reveal severe errors from given RT-SA/SD specifications. First results of the work demonstrate the applicability of the approach used. Keywords: Concurrent Program Design, Systems Modelling and Analysis, Formal Description Techniques, Embedded Systems
1. INTRODUCTION
1.2 The refined plans
Our overall objective is to enchance the process of developing embedded real-time control systems in the areas of making the development process visible at all stages, increasing productivity, shortening the development time and raising quality of the software product.
The refined plan to reach our all objectives was as follows: 1) to practically remove the coding and most of the detailed design stages and to create automatically the executable target code from the physical model of the system, and 2) to extensively reuse both well proven and tested pieces of system models, and design decisions in order to enforce the quality of the product.
As a starting point, Structured Analysis and Design for Real-Time Systems (RT-SA/SD) methodology [11] was selected to be used for modeling the behaviour and architecture of the system. With these goals the main modeling tools in the RT-SA/SD were the Data Flow Diagram and the State Transition Diagram. According to our experiences gained from applying manually the RT-SAJSD techniques to the development projects, the main impact on our objectives was the improvement of software quality and a shortened testing stage. However, the use of RT-SA/SD did not provide significant improvements in productivity or the throughput time.
Because we found that the current available commercial CASE-tools do not in general provide these facilities [5,10], we had to: 1) define a more formal methodology as a backbone of the structured techniques, 2) implement a set of program transformation mechanisms for generating high level target language code from the refined structured models, 3) implement a set of analysis and animation tools to support the verification of the models,
1.1 Background
52
A. Auer et aL / Automated Code Generation
4) provide links to domain-specific extensions of the system models, as well as to the related design decision knowledge, and 5) integrate these tools with a CASE system for real-time applications. In particular, the program transformation system must be able to implement the complete behaviour of the behavioural models of the system so that we can end the era of developing systems by patching source code.
1.3 E x i s t i n g T r a n s f o r m a t i o n Applications
Systems for Real.Time
The transformational software construction [3,4,9] paradigm that we chose as the backbone of our approach looked very promising, but we realized from the beginning that more work is needed to develop this approach to a true alternative for the traditional software production schemes. There are very few systems for generating full code from high level specifications in the domain of embedded real-time systems [5]. The transformational software construction paradigm is typically applied on small scale problems in sequential applications producing Lisp-code. The use of Lisp as an executable target code is out of question in the real-time systems. The modest results in the real-time domain are partly due to complexity of domain itself and partly due to limitations of the transformation mechanisms. In Native-Refine [2], communications systems domain, a subset of real-time systems is covered. The real-time behaviour of the system is described by extending the basic predicate logic formalism in Refine with a set of temporal logic primitives. The basic transformation mechanism of Refine preserves the correctness of the transformations. In the real-time domain, however, the correctness of the transformations can not be preserved in all cases. To overcome this shortcoming, the real-time extension provides a mechanism for generating or propagating conditions that can be tested to verify the correctness of the transformations.
2. AN OVERVIEW OF THE DEVELOPED TRANSFORMATION APPROACH The domain languages in our transformation approach are defined as a set of components [8] that represent the objects and operations in the domain. The component instances are defined as component types which have a typed interface, network of subcomponents and a tree of operand components. A component is called: - a basic component if it has no subcomponents nor operand components, - a operator if it has operands and - a compound component if it has subeomponents.
The typed interface is essential to our system at least in three ways: 1) it ensures the consistency of the constructed models both before and after the transformation steps, 2) it is a mechanism for indexing families of compatible variants of components of the models, such as RT-SA/SD-transformations and 3) it includes real-time connector primitives for connecting asynchronous components. In our approach the components are connected to a hierarchical network. A component communicates with its environment using structured and strongly typed connectors. The component in the bottom of the hierarchy can be a simple variable or it can act as an operator manipulating other components. In real-time domain, the network describes the concurrency and the operator tree describes the sequential computation. Our component model has some similarities with the Object Oriented Design and some hardware description languages [6]. In the transformation process, the connections are used to pass fragments of transformation results of a component to the places they are used in the target model. Explicit source level connectors are used to implement communication of interactive components. Implicit target level connectors are used to re-organize the structure of the system. The different transformation results of a component are channeled simultaneously through its connectors. With this mechanism the most complex networks can be transformed into tree structure. The existing transformation mechanism is implemented in Prolog which provides built-in mechanisms for pattern-matching and shared variables for channelling delayed transformation results. Also the required procedural transformation rules in each component are easy to implement in Prolog.
THE RT-SA/SD DOMAIN FOR DESIGNING REAL-TIME SYSTEMS 3.
Since the selected method, RT-SA/SD, showed to have a vague specification, we had to refine the notation and its semantics for the DFD and the STD. Moreover, some extensions has been introduced to support the reusability of the RT-SA/SD designs. We have refined RT-SA/SD with an introduction of a minispec language to express actual computation, hierarchically atomic interpretation [7] of system behaviour, liberalization of transition conditions and actions, and an introduction of bubble types. The formal minispec language is needed to avoid the confusion of vague specifications. The liberalization of transitions allows the use of minispec language in condition and action. The bubble types facilitates the reuse of bubbles without explicit instantiation to the bottom. The principle of hierarchical atomicity simplifies the design and behaviour of components. This is discussed in the next chapter.
A. Auer et aL / Automated Code Generation
Human Knowledge
53
User Defined Components
~'~..~
f____> Application
/M o d e l
> Target Level
///
Code )
SDeAf'iCitimPn°nent
y~
J
SA Transformation Rules
~2Pi2biln
~ode ~
/
~
Figure 1. The use of program transformation in software production. The RT-SA/SD concepts have been embedded into our component model. In general, the RT-SA/SD concepts (in the Data Flow Diagram and the State Transition Diagram) have a simple component definition, as shown in table 1 and example in figure 2. The Entity Relationship Diagram was not modeled. I RT-SA/SD item I
I Component I definition
I
I
I bubble I flag I signal I discrete flow I discrete transformation I state machine I minispec language I store I variable
I Compound I Compound I Compound I Compound I Operator I Operator I Operator I Basic I Basic
I
I
Table 1. The RT-SA/SD domain in component model
Figure 2. A RT-SA/SD flag defined as a component.
4.
INTERNAL
Executable Code
SCHEDULING
OF
RT-SA/SD
COMPONENTS The scheduling of the RT-SA/SD components is based on the assumption of well-behaving components and on a hierarchically atomic interpretation of the RT-SA/SD description, which differs significantly from Ward's interpretation [12] where activations are propagated in depth-first order. The hierarchical atomicity is based on the practical observation that concurrency of the system description is not always vital for the purpose of the system. Concurrent sequences can be interleaved without changing the externally observable behaviour. System description can be divided to mutually concurrent blocks, which are internally implemented as sequential programs. Hierarchical atomicity means that when a component is activated by an impulse (caused by an external event) the execution is completed at each hierarchy level before accepting the next activation. After completing at a level the execution is transferred to a neighbouring component, or returned to an upper level if no neighbours have been activated. Prior to compilation the components must be grouped into tasks of different priorities according to timing constraints. So, the components of the same task do not interrupt each others, but the tasks do according to their priority level. This scheduling principle reduces the amount of tasks to a minimum. The internal scheduling in task component accomplished by using simple Boolean variables.
is
54
A. Auer et aL / Automated Code Generation
5. A N A L Y S ~ OF GENERATED CODE
7. CONCLUSION
In the first phase an operational prototype was developed in order to test the transformation process and the logical behaviour of generated code. Also the effectiveness of the internal scheduling policy and the task interface were examined. Then these results should be used to develop the actual transformation system into a software production system.
The results of the prototype experiments showed the practical applicability of chosen design methodolology and transformation approach. The prototype is redesigned according to the experiences. The current transformer produces functional source code and a task body from a RT-SA/SD-model fast enough to facilitate the interactive use of code generation. The transformation time seems to be linear according to the number of components in the system.
In the prototype, the resulting block of code implementing the RT-SA/SD model for a task is one compilation module. All information between the module and its environment is transferred via parameters. A status block containing e.g. state variables and data stores, is transferred as a parameter to allow re-entrant use of the modules. All variables are global within a module which allows the use of parametefless procedures. The prototype has been tested with a part of a real embedded application. The input contained three data flow diagrams, four state machines with a total of 27 states and 57 transitions, and four discrete transformation bubbles. Transitions and discrete transformation bubbles contained 70 lines of algorithmic specification. Fully automatic generation of this specification to a commercial high level language (PL/M-86) takes 180 seconds in a time-shared MV 10000-computer. The size of the generated code was five kbytes (1190 lines source code) and its response time to a certain event was 0.9 ms. The same system implemented manually yielded to 3.5 kbytes and 0.8 ms respectively. The resulting code was tested using a high-level debugger. The testbed routine was a simple program, which set the parameter values and called the generated module for each event. Testing was straightforward and fast due to close relationships between RT-SA/SD-concepts and the code. In fact, the need of program listing was minimal. The generated code fulfilled all behavioural requirements of the specified RT-SA/SD-model.
6. THE DYNAMIC ANALYSER The transformer was also used to create a PB-graph [13] for dynamic analysis of the RT-SA/SD-model. The PB-graphs are a modification of Petri nets by which the state space generation (reachability analysis) could be accomplished. From the viewpoint of the transformer this was done by changing the target level transformation rules. So far, the reachability analysis has been done for two RT-SA/SD-model, which both contained a severe hidden error. These results show the importance of testing the system in all design phases.
The developed transformer has shown its strength by being able to transform two totally different target level languages from the same source language. Both these examples included difficult data and control structure conflicts. We have good reasons to believe that the next target language implementation is no problem. The component model has a strong expressive power due to the flexibility of component and connetor types. This allows easy introduction of new basic components and connectors. The developed internal scheduling method was quite effective and the generated module code can be used in almost any operating system. The automatic code generation requires a new, accurate approach to the specification in each design phases. Some problems arose when old RT-SA/SD specifications were transformed automatically because they did not contain all the required information needed in the transformation. In fact, those specifications assumed certain implicit decision to be made in the implementation phase. ACKNOWLEDGEMENTS The authors wish to thank Kone Corp. for permission to publish this material. Also our colleagues, Antti Valmari and Timo Jokela at the Technical Research Centre of Finland, are appreciated for their work of interfacing the dynamic analyzer to the code generator. REFERENCES [1] Arango, G., Domain Engineering Paradigms for Reuse, University of California, Irvine, Department of Information and Computer Science, 1987. [2] Brown,T.C. and Markosian,L.Z., Knowledge-Based Real-Time Software Development: From Requirements to Code. National Conference on Methodologies and Tools for Real-Time Systems, 1986 19p. [3] Feather, M., A Survey and Classification of Some Program Transformation Approaches and Techniques, IFIP WG2.1 Working Conference on Program Specification and Transformation, Bad Ttlz, Germany, April 1986. 27 p.
A. Auer et aL / Automated Code Generation
[4] Kalaoja, J., The Description and Realization of Real-Time Software in Certain Transformation Systems. University of Oulu, Department of Electronic Engineering Finland 1988. [5] N.N., CASE Tools for Real-Time Analysis and Design, CASE Outlook, vol.2, no 1, January 1988. [6] Larsson, T., On the Specification and Verification of VLSI Systems. Department of Computer and Information Science,Link6ping, Sweden 1986.
[9] Partsch, H. and Steinbrueggen, R., Program Transformation Systems, ACM Computing Surveys, Vol. 15, No. 3, Sept. 1983, pp. 199-236. [ 10] Ward, P.T., Comparing Real-Time Techniques, CASE Outlook, vol.2, no 1, January 1988. [11] Ward, P.T. and Mellor, S.J., Structured Development for Real-Time Systems, Vol. 1-3. Yourdon Press, N.Y. 1986.
[7] Okkonen, A. and Auer, A., Serialized Implementation of Concurrent Real-Time Programs, in print.
[12] Ward, P.T., The Transformation Schema: An Extension of the Data Flow Diagram to Represent Control and Timing. IEEE Trans. on Software Engineering 12(1986)2, pp. 198-210.
[8] Okkonen, A. and Auer, A., Coupled Component Formalism for Functional Modelling of RealTime Systems, in print.
[13] Valmari, A., PC-RIMST - A Tool for Validating Concurrency Program Designs, this volume.
55
51
AUTOMATED CODE GENERATION OF EMBEDDED REAL-TIME SYSTEMS Antti Auer * Pekka Kemppainen ** Ari Okkonen * Veikko Seppgnen * * Technical Research Centre of Finland Computer Technology Laboratory P.O.Box 181, SF-90101 Oulu FINLAND ** Kone Corp. Research Centre P.O.Box 6, SF-05801 Hyvink/i~i FINLAND
A code generator is presented, ltproducesfull tasks for real-time systems from a structured data/control flow description. The work is based on ideas behind the RT-SA/SD methodology and program transformation paradigm. The code generator is written in Prolog. It is now capable of producing programs in PL/M-86 language for realistic applications and Petri nets for dynamic analysis. The resulting code has been found effective. The dynamic analysis has proven its ability to reveal severe errors from given RT-SA/SD specifications. First results of the work demonstrate the applicability of the approach used. Keywords: Concurrent Program Design, Systems Modelling and Analysis, Formal Description Techniques, Embedded Systems
1. INTRODUCTION
1.2 The refined plans
Our overall objective is to enchance the process of developing embedded real-time control systems in the areas of making the development process visible at all stages, increasing productivity, shortening the development time and raising quality of the software product.
The refined plan to reach our all objectives was as follows: 1) to practically remove the coding and most of the detailed design stages and to create automatically the executable target code from the physical model of the system, and 2) to extensively reuse both well proven and tested pieces of system models, and design decisions in order to enforce the quality of the product.
As a starting point, Structured Analysis and Design for Real-Time Systems (RT-SA/SD) methodology [11] was selected to be used for modeling the behaviour and architecture of the system. With these goals the main modeling tools in the RT-SA/SD were the Data Flow Diagram and the State Transition Diagram. According to our experiences gained from applying manually the RT-SAJSD techniques to the development projects, the main impact on our objectives was the improvement of software quality and a shortened testing stage. However, the use of RT-SA/SD did not provide significant improvements in productivity or the throughput time.
Because we found that the current available commercial CASE-tools do not in general provide these facilities [5,10], we had to: 1) define a more formal methodology as a backbone of the structured techniques, 2) implement a set of program transformation mechanisms for generating high level target language code from the refined structured models, 3) implement a set of analysis and animation tools to support the verification of the models,
1.1 Background
52
A. Auer et aL / Automated Code Generation
4) provide links to domain-specific extensions of the system models, as well as to the related design decision knowledge, and 5) integrate these tools with a CASE system for real-time applications. In particular, the program transformation system must be able to implement the complete behaviour of the behavioural models of the system so that we can end the era of developing systems by patching source code.
1.3 E x i s t i n g T r a n s f o r m a t i o n Applications
Systems for Real.Time
The transformational software construction [3,4,9] paradigm that we chose as the backbone of our approach looked very promising, but we realized from the beginning that more work is needed to develop this approach to a true alternative for the traditional software production schemes. There are very few systems for generating full code from high level specifications in the domain of embedded real-time systems [5]. The transformational software construction paradigm is typically applied on small scale problems in sequential applications producing Lisp-code. The use of Lisp as an executable target code is out of question in the real-time systems. The modest results in the real-time domain are partly due to complexity of domain itself and partly due to limitations of the transformation mechanisms. In Native-Refine [2], communications systems domain, a subset of real-time systems is covered. The real-time behaviour of the system is described by extending the basic predicate logic formalism in Refine with a set of temporal logic primitives. The basic transformation mechanism of Refine preserves the correctness of the transformations. In the real-time domain, however, the correctness of the transformations can not be preserved in all cases. To overcome this shortcoming, the real-time extension provides a mechanism for generating or propagating conditions that can be tested to verify the correctness of the transformations.
2. AN OVERVIEW OF THE DEVELOPED TRANSFORMATION APPROACH The domain languages in our transformation approach are defined as a set of components [8] that represent the objects and operations in the domain. The component instances are defined as component types which have a typed interface, network of subcomponents and a tree of operand components. A component is called: - a basic component if it has no subcomponents nor operand components, - a operator if it has operands and - a compound component if it has subeomponents.
The typed interface is essential to our system at least in three ways: 1) it ensures the consistency of the constructed models both before and after the transformation steps, 2) it is a mechanism for indexing families of compatible variants of components of the models, such as RT-SA/SD-transformations and 3) it includes real-time connector primitives for connecting asynchronous components. In our approach the components are connected to a hierarchical network. A component communicates with its environment using structured and strongly typed connectors. The component in the bottom of the hierarchy can be a simple variable or it can act as an operator manipulating other components. In real-time domain, the network describes the concurrency and the operator tree describes the sequential computation. Our component model has some similarities with the Object Oriented Design and some hardware description languages [6]. In the transformation process, the connections are used to pass fragments of transformation results of a component to the places they are used in the target model. Explicit source level connectors are used to implement communication of interactive components. Implicit target level connectors are used to re-organize the structure of the system. The different transformation results of a component are channeled simultaneously through its connectors. With this mechanism the most complex networks can be transformed into tree structure. The existing transformation mechanism is implemented in Prolog which provides built-in mechanisms for pattern-matching and shared variables for channelling delayed transformation results. Also the required procedural transformation rules in each component are easy to implement in Prolog.
THE RT-SA/SD DOMAIN FOR DESIGNING REAL-TIME SYSTEMS 3.
Since the selected method, RT-SA/SD, showed to have a vague specification, we had to refine the notation and its semantics for the DFD and the STD. Moreover, some extensions has been introduced to support the reusability of the RT-SA/SD designs. We have refined RT-SA/SD with an introduction of a minispec language to express actual computation, hierarchically atomic interpretation [7] of system behaviour, liberalization of transition conditions and actions, and an introduction of bubble types. The formal minispec language is needed to avoid the confusion of vague specifications. The liberalization of transitions allows the use of minispec language in condition and action. The bubble types facilitates the reuse of bubbles without explicit instantiation to the bottom. The principle of hierarchical atomicity simplifies the design and behaviour of components. This is discussed in the next chapter.
A. Auer et aL / Automated Code Generation
Human Knowledge
53
User Defined Components
~'~..~
f____> Application
/M o d e l
> Target Level
///
Code )
SDeAf'iCitimPn°nent
y~
J
SA Transformation Rules
~2Pi2biln
~ode ~
/
~
Figure 1. The use of program transformation in software production. The RT-SA/SD concepts have been embedded into our component model. In general, the RT-SA/SD concepts (in the Data Flow Diagram and the State Transition Diagram) have a simple component definition, as shown in table 1 and example in figure 2. The Entity Relationship Diagram was not modeled. I RT-SA/SD item I
I Component I definition
I
I
I bubble I flag I signal I discrete flow I discrete transformation I state machine I minispec language I store I variable
I Compound I Compound I Compound I Compound I Operator I Operator I Operator I Basic I Basic
I
I
Table 1. The RT-SA/SD domain in component model
Figure 2. A RT-SA/SD flag defined as a component.
4.
INTERNAL
Executable Code
SCHEDULING
OF
RT-SA/SD
COMPONENTS The scheduling of the RT-SA/SD components is based on the assumption of well-behaving components and on a hierarchically atomic interpretation of the RT-SA/SD description, which differs significantly from Ward's interpretation [12] where activations are propagated in depth-first order. The hierarchical atomicity is based on the practical observation that concurrency of the system description is not always vital for the purpose of the system. Concurrent sequences can be interleaved without changing the externally observable behaviour. System description can be divided to mutually concurrent blocks, which are internally implemented as sequential programs. Hierarchical atomicity means that when a component is activated by an impulse (caused by an external event) the execution is completed at each hierarchy level before accepting the next activation. After completing at a level the execution is transferred to a neighbouring component, or returned to an upper level if no neighbours have been activated. Prior to compilation the components must be grouped into tasks of different priorities according to timing constraints. So, the components of the same task do not interrupt each others, but the tasks do according to their priority level. This scheduling principle reduces the amount of tasks to a minimum. The internal scheduling in task component accomplished by using simple Boolean variables.
is
54
A. Auer et aL / Automated Code Generation
5. A N A L Y S ~ OF GENERATED CODE
7. CONCLUSION
In the first phase an operational prototype was developed in order to test the transformation process and the logical behaviour of generated code. Also the effectiveness of the internal scheduling policy and the task interface were examined. Then these results should be used to develop the actual transformation system into a software production system.
The results of the prototype experiments showed the practical applicability of chosen design methodolology and transformation approach. The prototype is redesigned according to the experiences. The current transformer produces functional source code and a task body from a RT-SA/SD-model fast enough to facilitate the interactive use of code generation. The transformation time seems to be linear according to the number of components in the system.
In the prototype, the resulting block of code implementing the RT-SA/SD model for a task is one compilation module. All information between the module and its environment is transferred via parameters. A status block containing e.g. state variables and data stores, is transferred as a parameter to allow re-entrant use of the modules. All variables are global within a module which allows the use of parametefless procedures. The prototype has been tested with a part of a real embedded application. The input contained three data flow diagrams, four state machines with a total of 27 states and 57 transitions, and four discrete transformation bubbles. Transitions and discrete transformation bubbles contained 70 lines of algorithmic specification. Fully automatic generation of this specification to a commercial high level language (PL/M-86) takes 180 seconds in a time-shared MV 10000-computer. The size of the generated code was five kbytes (1190 lines source code) and its response time to a certain event was 0.9 ms. The same system implemented manually yielded to 3.5 kbytes and 0.8 ms respectively. The resulting code was tested using a high-level debugger. The testbed routine was a simple program, which set the parameter values and called the generated module for each event. Testing was straightforward and fast due to close relationships between RT-SA/SD-concepts and the code. In fact, the need of program listing was minimal. The generated code fulfilled all behavioural requirements of the specified RT-SA/SD-model.
6. THE DYNAMIC ANALYSER The transformer was also used to create a PB-graph [13] for dynamic analysis of the RT-SA/SD-model. The PB-graphs are a modification of Petri nets by which the state space generation (reachability analysis) could be accomplished. From the viewpoint of the transformer this was done by changing the target level transformation rules. So far, the reachability analysis has been done for two RT-SA/SD-model, which both contained a severe hidden error. These results show the importance of testing the system in all design phases.
The developed transformer has shown its strength by being able to transform two totally different target level languages from the same source language. Both these examples included difficult data and control structure conflicts. We have good reasons to believe that the next target language implementation is no problem. The component model has a strong expressive power due to the flexibility of component and connetor types. This allows easy introduction of new basic components and connectors. The developed internal scheduling method was quite effective and the generated module code can be used in almost any operating system. The automatic code generation requires a new, accurate approach to the specification in each design phases. Some problems arose when old RT-SA/SD specifications were transformed automatically because they did not contain all the required information needed in the transformation. In fact, those specifications assumed certain implicit decision to be made in the implementation phase. ACKNOWLEDGEMENTS The authors wish to thank Kone Corp. for permission to publish this material. Also our colleagues, Antti Valmari and Timo Jokela at the Technical Research Centre of Finland, are appreciated for their work of interfacing the dynamic analyzer to the code generator. REFERENCES [1] Arango, G., Domain Engineering Paradigms for Reuse, University of California, Irvine, Department of Information and Computer Science, 1987. [2] Brown,T.C. and Markosian,L.Z., Knowledge-Based Real-Time Software Development: From Requirements to Code. National Conference on Methodologies and Tools for Real-Time Systems, 1986 19p. [3] Feather, M., A Survey and Classification of Some Program Transformation Approaches and Techniques, IFIP WG2.1 Working Conference on Program Specification and Transformation, Bad Ttlz, Germany, April 1986. 27 p.
A. Auer et aL / Automated Code Generation
[4] Kalaoja, J., The Description and Realization of Real-Time Software in Certain Transformation Systems. University of Oulu, Department of Electronic Engineering Finland 1988. [5] N.N., CASE Tools for Real-Time Analysis and Design, CASE Outlook, vol.2, no 1, January 1988. [6] Larsson, T., On the Specification and Verification of VLSI Systems. Department of Computer and Information Science,Link6ping, Sweden 1986.
[9] Partsch, H. and Steinbrueggen, R., Program Transformation Systems, ACM Computing Surveys, Vol. 15, No. 3, Sept. 1983, pp. 199-236. [ 10] Ward, P.T., Comparing Real-Time Techniques, CASE Outlook, vol.2, no 1, January 1988. [11] Ward, P.T. and Mellor, S.J., Structured Development for Real-Time Systems, Vol. 1-3. Yourdon Press, N.Y. 1986.
[7] Okkonen, A. and Auer, A., Serialized Implementation of Concurrent Real-Time Programs, in print.
[12] Ward, P.T., The Transformation Schema: An Extension of the Data Flow Diagram to Represent Control and Timing. IEEE Trans. on Software Engineering 12(1986)2, pp. 198-210.
[8] Okkonen, A. and Auer, A., Coupled Component Formalism for Functional Modelling of RealTime Systems, in print.
[13] Valmari, A., PC-RIMST - A Tool for Validating Concurrency Program Designs, this volume.
55