a case study in simulation-based system specification and design

A CASE STUDY IN SIMULATION-BASED SYSTEM SPECIFICATION AND DESIGN J.M. van de Mortel-Fronczak*, R.J.A. Gorter**, and J.E. Rooda* *Eindhoven University of Technology, Department of Mechanical Engineering, P.O. Box 513, 5600 MB Eindhoven, The Netherlands, E-mail: [email protected], [email protected] **TNO Institute of Industrial Technology, Department of Mechatronics, P.O. Box 6235, 5600 HE Eindhoven, The Netherlands, E-mail: [email protected] KEYWORDS System engineering, control systems, simulation and validation.

ABSTRACT A good practice in developing control systems involves speci cation, validation/veri cation, and implementation. Speci ed models usually form a starting point for simulation-based validation, resulting in reducing the risk of design errors. If a proper abstraction level is chosen, the implementation of validated models can be a straightforward process. For the purpose of simulation-based validation as described in this paper, it is essential to include models of the machine to be controlled. This is implied by the fact that the main focus is on the performance of the controlled system. Nowadays, it is possible to automatically generate real-time code from (validated) models which allows for incremental system development. The purpose of this paper is to present a method that allows for simulation-based validation of control systems incorporating the issues described above and to indicate how the method can be applied in a relevant case study.

INTRODUCTION The performance and the functionality of complex integrated machines depend on the strong interaction between the control system and the machine hardware resources. The development of this kind of mechatronical products requires a strong interaction between mechanics, electronics and (control) software during the complete development process. The development of the complete machine including control starts with a thorough analysis of user requirements that describe the required machine functionality and performance. From the user requirements, concept speci cations for both the machine hardware and the control components are derived during the concept development phase. These speci cations form the guidelines for the next phases of the development pro-

cess. Therefore, it is very important that the speci cations are correct, meaning that if the control system and the hardware work each according to their own speci cation, then the machine should ful l the user requirements. Simulation is a powerful tool that can be used in the concept-development phase to determine, describe, and validate these speci cations. As simulation can be used early in the development process, simulation-based validation reduces the risk of expensive concept-design errors. Depending on the purpose, simulation models can be formulated on dierent abstraction levels, as shown in (Mauw and Veltink 1990), (David and Alla 1994), (Cuypers 1994), (van de Mortel-Fronczak et al. 1995), (Balarin et al. 1997), and (Rankers 1997). Additionally, if a proper abstraction level is chosen, the implementation of validated control models can be a straightforward process (Spronk 1998). Ideally, the model can be used for the actual machine control directly. For the purpose of simulation-based system validation, it is essential to include models of the machine to be controlled. Especially in the case of complex machines (for instance, wafer steppers and scanners), it is important to determine a suitable form of machine models necessary to perform ecient simulation experiments. The purpose of this paper is to present a simulation-based method able to satisfy the development process requirements described above. As nowadays complex machines consist of many components performing their actions in parallel, it seems justi able to use a speci cation formalism which exploits this parallel character: for instance, Petri nets (David and Alla 1994) or parallel processes (Burns and Davies 1993). In this paper, a speci cation method based on the concepts derived from Communicating Sequential Processes (Hoare 1985) is used. The general idea is that machines are treated as collections of independent components that interact by exchanging information through communication channels (van de Mortel-Fronczak et al. 1995). The paper is structured as follows. In Section 2, a simulation approach to the design of complex devices and their control systems is discussed. Section 3 elaborates a case study. In Section 4, concluding

remarks are presented.

c machine model c compiler

SIMULATION APPROACH TO THE DESIGN OF COMPLEX DEVICES In this section, we discuss a simulation approach to the design of complex machines and their control systems. Nowadays, exibility of machines is often achieved by incorporating a substantial amount of (embedded) software, which performs control and measurement tasks. As a consequence, the complexity of the design process increases. At the same time, the customers demand that the machines are reliable and the development time is short. To control complexity of the design process, methods supported by validation and veri cation tools similar to hardwaresoftware co-design methods like POLIS (Balarin et al. 1997) or SACRES (Benveniste 1998) are needed. In this paper, a rst step in this direction is presented: a development method based on the Communicating Sequential Processes-like (Hoare 1985) speci cation language  (van de Mortel-Fronczak et al. 1995). The method allows for precise and clear speci cation of both the dynamic behaviour of machine hardware and the control system. It also provides access to fast simulation tools (Naumoski and Alberts 1998) as well as a fast, easy, and fault-free translation of control components to the real-time implementation platform VxWorks (Hofkamp 2000). The translation can easily be adopted to other real-time platforms that comply to the POSIX (the Portable Operating System Interface) standard. In , a machine is modelled by a nite set of processes and a nite set of channels used for communication or synchronization among the processes. Processes model components of the machine and channels model the connections among them. The view of machines as collections of cooperating independent components can be derived from general ideas of concurrent programming (Burns and Davies 1993). The behaviour of components can be speci ed by concurrent programs. The resulting speci cations, which are called models in the sequel, can be validated by sequential or distributed simulation (Misra 1986). Control systems can be viewed in the same way. In the development of machines and associated control systems, three stages can be distinguished (Hofkamp 2000): 1. Concept design User requirements form the input of this stage. Using the requirements as a starting point, the dynamic behaviour of the machine and a proper way to control it is speci ed. For this purpose, models of the machine and its control system are developed, simulated, and analysed. The emphasis in this stage lies primarily on validating whether the user requirements are ful lled.

c control model

real-time c compiler

C++ code

c simulator

simulation output for validation purposes

C++ code VxWorks

I/O interface

machine

Figure 1: Simulation and implementation using  speci cations 2. Physical design This stage is meant to precisely de ne how the control system interacts with the sensors and actuators. Models with an accurate description of the sensors and actuators of the machine are developed, and the control system is adapted to match the changes. Moreover, the model can be used for evaluation of system performance trade-os. For example, the selection of controller hardware components, such as processor or bus structure, can be well motivated as control structure/complexity and communication intensity are known and validated in the concept model. 3. Implementation and testing In this stage, the control system is moved to the real-time platform. For correct real-time functionality, the calculations should be performed within wellde ned time periods. Therefore, it is important to assess the impact of the duration of calculations on communication behaviour. In case of dierences with respect to the behaviour in simulation time, correctness analysis has to be performed, which can give rise to changes in the design. Eventually (after downloading) the control system operates the real machine through an I/O interface. The rst two development stages deliver virtual machines models, which are accurate descriptions of machines, and accurate descriptions of control systems. In the last stage, the virtual machine model is replaced by its real counterpart, and the control system is applied in the real-time environment without modi cations, as shown in Figure 1. When modelling hardware, a certain abstraction has to be made of the physical behaviour of the actuators and sensors present in the machine. Most important is that the control system does not dierentiate between the virtual and the real hardware. Movements, for instance, can be modelled by time delays giving rise to the discrete model scheme of

Controller

on/off

C

Sensor

H1

Hardware

Figure 4: Controller and two hardware components

Figure 2: Discrete model scheme Controller

start /setpoint

Controller

ready

Feedback controller

start /setpoint

H2



If hardware or its prototype are available, they can be tested in combination with the realtime executable automatically generated from the controller model. This speeds up the test process, because the design of the controller, for instance, for the prototype test setup is fast and easy.



In principle, the real-time executable of the controller can be used in a VxWorks environment to control the hardware (machine) directly. However, often the controller should be implemented on a dedicated, low cost embedded microcontroller. Real-time testing of this embedded microcontroller, even if no hardware is available, is possible as the virtual hardware model can automatically be transformed into a real-time executable.



If only a part of the hardware is available (component H1 in our example), real-time models of the remaining hardware components and the controller can be used to test only the available hardware components. The model of the hardware components now simulates in real-time the communication interaction with the hardware component that should be tested. This allows an incremental hardware development approach, where rst one component is designed, build and tested before the design of the next component is started. Of course, a similar approach can be followed for the controller development.

ready

Feedback controller and hardware

Sensor

Hardware

Figure 3: Hybrid model schemes Figure 2. In this scheme, hardware and sensors are modelled as discrete components. They can also be modelled using dierential equations (van Beek and Rooda 1998) giving rise to hybrid model schemes of Figure 3. In the hybrid model schemes, hardware is controlled by a feedback controller. Both components are modelled as combined discrete-continuous components. The only dierence between the two hybrid model schemes is that in the rst one, sensors are modelled explicitly and in the second one, they are integrated in the model of the feedback controller and hardware. Hardware components with similar behaviour can be modelled by the same parametric process (van de Mortel-Fronczak et al. 1995). In the rst place, specifying and modelling of machines and their control is essential for the conceptdesign stage. However, since properly de ned  control models can be applied in the real-time environment without modi cations (Hofkamp 2000), machine and control models are of importance in the implementation and testing stage, as well. Namely, they can be used in various forms of the hardwarein-the-loop simulation (Isermann 1997), as discussed in the sequel. Assume the presence of the model in which a controller and two hardware components can be distinguished, as shown in Figure 4. There are several modes in which the elements of this model can be used during the implementation and test phase:

CASE STUDY This section describes how the approach presented above has been applied in the development of an automatic chemical analyser. Currently, the analyser project is half way in the design phase, hence the focus in this paper is on the concept development phase. In all project phases, the  language with the associated speci cation method and software tools (Naumoski and Alberts 1998) is used. In the project, Systems Engineering Group from the Eindhoven University of Technology and Department of Mechatronics from the TNO Institute of Industrial Technology work together.

adding reagent

R1

T

adding sample

S

tinc1

performing measurement

re a g e n t ro to r

te s t-tu b e s ro to r

s a m p le r o to r

M

1-reagent test

R1

T

S

tinc1

R2

tinc2

S e n s o r

M

2-reagent test

R1

T

S

tinc1

R2

tinc2

R3

tinc3

M

3-reagent test heating time

incubation time

Figure 5: Dierent test classes The main user requirements for the automatic chemical analyser are:  Function In the analyser, one or more reagents are added to liquid samples at speci ed time instances (incubation time). After a prescribed reaction time, the resulting mixture is measured.  Performance The analyser must be able to perform a speci ed number of tests per hour. It must be possible to perform dierent test types simultaneously. Tests de ned for samples can be divided into three dierent classes: 1-, 2-, and 3-reagent tests (see Figure 5). The incubation times necessary for chemical reactions can have dierent values. In order to obtain correct test results, it is important that the pipetting actions are performed after the desired incubation time within the speci ed tolerance. In the rst stage, concepts for the machine hardware and for the control structure are selected. Of course, there is a strong dependency between these two concepts. After a thorough analysis of dierent possible solutions, where the user requirements played an important r^ole, one overall concept has been chosen. The most important hardware elements in this concept are (see Figure 6):  Rotors for storing the reagent, sample and test tubes.  A reagent and a sample crank for pipetting reagents and samples into the test tubes.  Washing places for the pipetting needles of the cranks.  Washing place for the test tubes. The analyser control is divided into two layers: the instrument-control layer and the resource layer, as shown in Figure 7. The instrument-control layer ensures that the hardware resources ful l the tasks that are requested by the user. The main functions of this layer are: scheduling of tests and processing of the data generated by the resources (that is, measurements). The resource control ensures that the

re a g e n t c ra n k

w a s h u n its

s a m p le c r a n k

Figure 6: Schematic hardware con guration User interface

Scheduler

Data processing

Instrument control layer

Data generated

Schedule to be executed Resource control Resources

Resource layer

Figure 7: Layered control structure actual movements of the cranks and rotors, as well as pipetting actions, are performed at the right moment and within the allowed time span. The resource layer interacts with the higher control layer in two ways. From the instrument-control layer, the resource layer receives schedules to be executed. Furthermore, the resource layer sends measurement data to the instrument control layer. The measurements are not considered in the project described in this paper. Based on the concept proposed and on a thorough analysis of the user requirements, speci cations for the hardware resources (for instance, the speed of the crank movements and of the pipetting actions), the resource controller (for instance, the order in which hardware resources should operate), and the instrument controller are derived. During the concept-design stage,  has been used to model the control system and hardware resources in order to determine and validate speci cations for the dierent components. The speci cations can be summarized in the hardware cycles, which depend on the test class. Hardware cycles determine the order and duration of dierent actions that have to be performed. As an example, in Figure 8 the hardware cycle for 1-reagent tests is shown. The rst development stage results in the model presented in Figure 9. This model has a heterarchical structure (Dilts et al. 1993), meaning that control components in the same layer (associated with hardware elements mentioned above) interact with each

Cycle-based

reagent rotor (RR) pipet up sample crank (SC)

pipet out (and stirr)

sample rotor (SR)

hold still

waiting time

reagent crank (RC)

initiation time

move cuvette rotor (CR)

Figure 8: Hardware cycle for 1-reagent tests te s ts

Figure 10: Variability on waiting time

wash

measure



meets throughput demands,



can process dierent classes of tests in a mixed order, given the restrictions of the analyser hardware, initiates every test within a certain time after it is requested, can handle continuous loading of samples.

s c h e d u le r

  c y c le d is p a tc h e r

re a g e n t ro to r c o n tr o lle r

c y c le

re a d y

re a d y s ta rt /s e tp o in t

b u ffe r

te s t-tu b e s w a s h e r c o n tr o lle r

c o n tr o lle r

c o n tr o lle r

c o n tr o lle r

te s t-tu b e s ro to r

s a m p le c ra n k

s a m p le r o to r

re s o u rc e c o n tr o lle r c o n tr o lle r

re a g e n t c ra n k

c y c le

Figure 9: Model structure other. It consists of two parts separated by a dashed line. The part above the line models the instrumentcontrol layer and the part below the line corresponds to the resource layer (control and hardware). The buer always contains a feasible schedule, so cycles can be dispatched in time, even if the scheduler is still busy calculating a new schedule. All model components are de ned in the  language. The resource controller and the analyser hardware have primarily been designed for performing one type of tests with xed incubation times. The required exibility has to be achieved by the scheduler that must be able to on-line calculate feasible schedules such that the analyser:

The scheduler is continuously calculating an optimal order, in which the tests should be executed. Once a test is initiated it has to be nished. That is, it cannot be re-scheduled, interrupted, or stopped. The combination of the scheduler and the analyser hardware determines whether user requirements are ful lled. Therefore, to estimate the feasibility of the complete concept, the performance should be tested in an early stage of the development process. In this project, the analyser hardware and the control system have been modelled in  and validated by simulation experiments early in the concept-design stage. In principle, the scheduling algorithm uses cyclebased scheduling. This means that it tries to schedule a test initiation in each following time slot. In order to nd a suitable test, the tests are examined in the order in which they are requested. If a test does not t the schedule, it is skipped. This process is repeated until a suitable test has been found. As cyclebased scheduling cannot guarantee that each test is initiated within the required time, the scheduling algorithm is extended with test-based scheduling. According to this scheduling method, a time slot in the schedule must be found in which the test under consideration can be initiated. Simulation experiments have shown that the scheduler developed for the speci ed hardware ful ls throughput requirements. The combination of the two scheduling methods guarantees that tests are initiated within the required time span. Moreover, it reduces the variability on the waiting time of the tests in the system (see Figures 10 and 11). Originally, there were no user requirements with respect to variability. However, due to simulation experiments with the  models, it turned out that variability is an important factor for user satisfaction.

Combination cycle- / test-based

model of the machine. This implies that especially aspects related to real-time should very carefully be dealt with in simulation models.

waiting time

ACKNOWLEDGEMENTS initiation time

Figure 11: Reducing variability on waiting time Currently, the physical-design stage has been started. Based on the  speci cations, mechanical and electrical design speci cations of hardware components are being derived. The  control model developed in the previous stage allows for derivation of well-motivated selection criteria necessary for the discussion about implementation aspects, such as the choice of controller architecture and communication structure, or required processing power. In this stage, the  model is being extended to incorporate a detailed description of sensor and actuator characteristics that allows for a direct implementation on the real-time platform. In the implementation and testing stage, an incremental hardware development approach is going to be used. First the test-tubes rotor will be built and tested. Subsequently, the cranks will be added. Parts of the  model and parts of the hardware will be used for the hardware-in-the-loop simulation.

CONCLUDING REMARKS This paper illustrates the use of simulation in the development process of complex devices. By performing simulation experiments with virtual machine models speci ed in  a better understanding of the machine can be gained in the process of developing the hardware and the associated control system. Moreover, simulation-based validation of  models reduces the risk of design errors because speci cations of components can be validated. The  models can also be used to provide quantitative predictions about the performance of the machine. This is especially useful in cases where there is a strong functional and performance dependency between the controller and the hardware. Models speci ed in , which has formal operational semantics (Bos and Kleijn 2000), are unambiguous and can be used as a basis for formal veri cation techniques. The development method described in the paper has been successfully applied to a number of systems, for instance, (Spronk 1998), (Hesen 2000), and (Hofkamp 2000). Since, in the end, the aim of the method is to deliver a properly functioning control system determined by the available hardware resources, the emphasis is on de ning an accurate

The project described in this paper is founded by the Dutch Ministry of Education, Culture and Science, through a special programme for cooperative research in which Eindhoven University of Technology and TNO Institute of Industrial Technology take part. The authors would like to thank J. Vervoort and W.P.C. Spronk, the Mechanical Department students of Eindhoven University of Technology, for their valuable contribution to the project. The authors also thank M. van Lent and A. Hofkamp for their comments on the draft versions of the paper.

REFERENCES Balarin, F.; M. Chiodo; P. Giusto; H. Hsieh; A. Jurecska; L. Lavagno; C. Passerone; A. SangiovanniVincentelli; E. Sentovich; K. Suzuki; and B. Tabbara. 1997. Hardware-software co-design of embedded systems. The POLIS approach. Kluwer Academic Publishers. Benveniste, A. 1998. Safety Critical Embedded Systems Design: the SACRES approach. http://www.tni.fr/sacres. Bos, V. and J.J.T. Kleijn. 2000. Discrete  : a production systems modelling language. Technical report, Eindhoven University of Technology, Department of Mathematics and Computing Science, Eindhoven, The Netherlands. To appear. Burns, A. and G. Davies. 1993. Concurrent Programming. International Computer Science Series. Reading: Addison-Wesley. Cuypers, L. 1994. Using speci cation languages for the simulation of embedded systems. In R. Crosbie and J. Crawford (Eds.), Modeling and Simulation of Embedded Systems. The Society for Computer Simulation. David, R. and H. Alla. 1994. Petri Nets for Modeling of Dynamic Systems | A Survey. Automatica 30 (2), 175 { 202. Dilts, D.M.; N.P. Boyd; and H.H. Whorms. 1993. The Evolution of Control Architectures for Automated Manufacturing Systems. Journal of Manufacturing Systems 10 (1), 79 { 93. Hesen, P.M.C. 2000. Control of a clinical chemical analyser. Final report, Eindhoven University of Technology, Stan Ackermans Institute, Eindhoven, the Netherlands. To appear. Hoare, C.A.R. 1985. Communicating Sequential Processes. London, UK: Prentice{Hall International. Hofkamp, A.T. 2000. Reactive machine control. Ph. D. thesis, Eindhoven University of Technology, De-

partment of Mechanical Engineering, Eindhoven, the Netherlands. To appear. Isermann, R. 1997. Mechatronic systems. A challenge for control engineering. In Proceedings of American Control Conference. Mauw, S. and G.J. Veltink. 1990. A Process Speci cation Formalism. Fundamenta Informaticae 13, 85 { 139. Misra, J. 1986. Distributed Discrete-Event Simulation. Computing Surveys 18 (1), 39{65. Naumoski, G. and W. Alberts. 1998. A discreteevent simulator for Systems Engineering. Ph. D. thesis, Eindhoven University of Technology, Department of Mechanical Engineering, Eindhoven, the Netherlands. Rankers, A.M. 1997. Machine dynamics in mechatronic systems. Ph. D. thesis, Twente University of Technology, Department of Mechanical Engineering, Enschede, the Netherlands. Spronk, W.P.C. 1998. A -based workstation control system. Report SE 420187, Eindhoven University of Technology, Department of Mechanical Engineering, Eindhoven, the Netherlands. van Beek, D.A. and J.E. Rooda. 1998. Languages and Applications in Hybrid Modelling: Positioning of Chi. In Proc. 9th Symposium on Information Control in Manufacturing, Nancy, 77{82. van de Mortel-Fronczak, J.M.; J.E. Rooda; and L.A.J. de Gree. 1995. Real-time Concurrent Programming as a Structured Approach to Modelling of Manufacturing Systems. In Proceedings of FAIM'95, Stuttgart, Germany, 247{258. van de Mortel-Fronczak, J.M.; J.E. Rooda; and N.J.M. van den Nieuwelaar. 1995. Speci cation of a Flexible Manufacturing System Using Concurrent Programming. The International Journal of Concurrent Engineering: Research & Applications 3 (3), 187{194.