- Email: [email protected]
ASPECT-BASED METHODOLOGY FOR REAL-TIME EMBEDDED CONTROL SYSTEMS DESIGN
ASPECT-BASED METHODOLOGY FOR REAL-TIME EMBEDDED CONTROL SYSTEMS DESIGN Rédha Hamouche and Rémy Kocik COSI Lab, Groupe ESIEE Cite Descartes-BP 99- 2 Blaise Pascal – 93162 Noisy-Le-Grand Cedex, FRANCE {hamouchr, kocikr}@esiee.fr
Abstract: Designing real-time embedded control systems follows usually a V-process and requires various languages and tools. Each language/tool provides a design methodology, and defines its own terminology and semantic. This lack of consistency leads usually to a disconnected design process where the transformation of models is usually performed manually. Thus, errors may be introduced in the models. Correcting these errors lengthens the design lifecycle and time to market. In this paper, we propose a new methodology which aims to fill the gaps due to the lack of consistency by unifying the terminologies and semantics used, and reduces the time spent in translation and debugging. This methodology does not propose a new global language which is far from each domain concerns and where the leaning curve is longer. The goal is rather to provide a multi-facet design using aspect and component approaches, and relying on an unified system metamodel in order to link the semantic differences between control and real-time computing languages and tools. Keywords: Real-time embedded control systems, design methodology, aspect, components, metamodeling, MDA.
1. INTRODUCTION
distributed architectures composed of processors (DSP, RISC) and specific integrated circuits (ASIC, FPGA).
Real-time embedded control systems are pervasive in different domains and industries, going from household appliances to aerospace domains. These systems, called controllers, are built with combination of software and hardware components. They have to keep under control the evolution of an other physical system, called plant, in order to ensure that it evolves towards a desired state, despite external disturbances. The controller observes permanently the plant evolution through sensors and is able to apply actions on the plant through actuators.
Designing theses systems follows usually a Vprocess, which allows building a system step by step according to top-down and then bottom-up design flow. A typical V-process for real-time embedded control systems design can be decomposed into three major steps (Kocik and Sorel, 2004): system control analysis, system specification and system real-time implementation. The result of each step is a model which is refined in the next one, until the implementation step.
Designing real-time embedded control systems tends to be more and more difficult due to the strong cost constraints and the growing complexity of the used software and hardware components. The software deals with different application domains (robotics, video, telecom…), implemented onto heterogeneous
The system control analysis, usually performed by control engineers, is a modelling step where the behaviour of plant and controller (control law) is described by a mathematical model, using dedicated languages and tools (like Matlab/Simulink (Mathworks) or Scilab/Scicos (Inria)), in order to
249
model and analyse the plant and synthesize the control law.
model of computation. It only facilitates simulation of fixed priority scheduling of tasks with constant execution times (Henriksson, et al., 2005). Another approach like AADL (Architecture analysis and Design Language) is emerged recently for a high level design and evaluation of the architecture of embedded systems. They are powerful but the complexity of models can be higher. In fact, the different real-time/embedded concerns (safety, security, real-time constraints, scalability, etc.) are mixed in the models. When one of the concerns of the model needs to be modified, manipulating the parts of the model related to that concern can prove to be challenging since these parts are mixed with the elements from other concerns (De Niz and Feiler, 2007).
The software specification is usually achieved by computer science engineers in order to implement the mathematical equations resulting from the modeling step, to capture the structure of the software, and to specify the high-level implementation constraints (input/output latency, jitter, etc.). The system real-time implementation, realized by computer science engineers, corresponds to writing the controller as real-time software that will be executed on the hardware, and meets the implementation constraints. Usually, this implementation is described as a set of tasks, functions with real-time execution constraints (period, priority, deadline, etc.) and properties (execution duration, memory footprint, etc.). These tasks are scheduled in order to guarantee they meet the specified real-time constraints (Timmerman, 1999).
This paper proposes an aspect-based methodology to design real-time embedded control systems with a “clean” separation of concerns. It is based on the aspect-oriented paradigm (Kiczales, et al., 1997) and the component-based approach (Szyperski, 1999) which are presented in the sections 2 and 3. The section 4 presents the goals and an overview of this methodology. A tool implementing the methodology is briefly presented in the section 5, before the conclusion.
Along this design process, several actors belonging to different domains (control, computer science, realtime…) are involved. They use domain-oriented method, languages and tools. Therefore, produced models at the different steps are heterogeneous. They differ mainly by the specified functionality, real-time constraints and models of computation (MoC) (Lee and Sangiovanni-Vincentelli, 1996).
2. ASPECT-ORIENTED APPROACH The aspect-oriented approach addresses the separation of functional aspects and non functional aspects in a system description, in order to manipulate the system regarding specific aspects, rather than in its whole. The benefits of this approach in real-time embedded control systems was demonstrated in (Hamouche, 2004; Hamouche, et al., 2001; Hamouche, et al., 2002), where aspects describe separately the system functionalities and its models of computation and real-time constraints. This separation leads to avoid the usual interweaving between those aspects. Thus, designing a system as a set of aspects ensures a clear description; give an extra dimension of system reusability and increases configuration capacities. Functionalities and realtime constraints will have a true separation. Reuse and configuration of system development is easier than in a monolithic design. Modifying any functionalities or constraints does not alter the whole system description; but involves a recompilation of this description.
This heterogeneity of models introduces lacks of consistency in the system design and leads usually to a disconnected design process where translations between the steps are needed. These translations are error-prone because they are usually performed manually by engineers. These errors may appear very early in the development process and be propagated into further steps. They can be only detected in the validation steps. Thus, correcting these errors needs numerous backtrackings (reiterations of V-cycle) in the design process, which lengthens the design lifecycle and time to market. Furthermore, the inconsistency of models may affect the implementation of the control system by disturbing its stability and reducing its performance (Kocik, et al., 2005). Nowadays, there are research challenges to define methodology and tools which reduce the design time and cost, and ensure the consistency of models from system level to implementation level. Tools that allow a control design and real-time design are quite a few. Ptolemy (Ptolemy, 2004), Jitterbug (Cervin and Lincoln, 2003), TrueTime (Henriksson and Cervin, 2003), SynDEx (Lavarenne, et al., 1991) are examples of such tools. Unfortunately, they are, in general, specialized on a certain aspect of the codesign problem or impose some restrictions (Henriksson, et al., 2005). Ptolemy tool, for instance, imposes some restrictions by the timed-multitasking
As shown in Fig. 1, the user only acts on the separated aspects, instead of the tangled code (ordinary description). Thanks to the aspect compiler, called weaver, that generates an ordinary description to be compiled by a standard compiler.
250
separated description Designer
functionnality Aspect 1 Aspect 2 Aspect 3
designed with the control performance in mind (Kocik and Sorel, 2004).
Tangled description weaver
to standard compiler
4.2 Multi-facet Design The proposed methodology defines a collaborative development approach for control and computer science engineers, where they work on a common platform, in multi-faceted fashion, to build a homogeneous design. According to the design process steps, three collateral facets are defined:
Fig. 1. Design Process of the Aspect-oriented Approach
3. COMPONENT-BASED APPROACH
• • •
The software component-based approach is increasingly used in different domains; it promotes a rapid construction of applications and models by assembling components. In (Szyperski, 1999), a component is defined as an autonomous unit of composition that is sufficiently self-contained. It can be deployed independently and is subject to composition by third parties. Every component needs to be well separated from its environment and the other components. It interacts with the environment or other components by a well specified interface. Using this notion of interface, a component declares what it provides and requires as services, relating to its environment. As a consequence, this approach improves the abstraction and the reusability of models.
Control facet Specification facet Implementation facet
Control engineers and computer science engineers act mainly on their own facets using a dedicated language which is closed to the corresponding domain concerned. As illustrated in Fig. 2, all languages and facets rely on a common metamodel which unifies the terminology and semantical differences between domains. The facets descriptions are therefore inwardly inter-linked. Designers can quickly observe and analyse changes made by one facet on the other.
Control facet language
Control facet
Spec. facet
4. METHODOLOGY OVERVIEW
Specification facet language
Metamodel
4.1 Methodology Goals
Impl. facet
The main goal is to define a methodology which unifies the design steps into a common approach and tool. In other words, this methodology has to handle the complexity and heterogeneity of models by filling the gap between the steps of the design process. The description of control modelling and its specification and implementation must be supported in a same approach in order to lead to a homogeneous design, and improve the model consistency and tractability along the design lifecycle. Improving the consistency of models leads to reduce the time spent in model translation and debugging, and then reduce the number of backtracking in design process. Another way to reduce the design lifecycle is to define modular models that are easily reusable and configurable.
Impl. facet language
Fig. 2. Design Facets
4.3 Metamodel for Control System Design The proposed methodology aims to follow the MDA (Model-Driven Architecture) design process (OMG ; Bézivin and Gerbé, 2001). It defines a metamodel as a description pattern which is able to capture the three facets description, and provides a support for interoperability between models, PIM (PlateformIndependent Model) or PSM (Platform-Specific Model) (OMG ; Bézivin and Gerbé, 2001). The brief synopsis of this pattern is drawn in Fig. 3 with UML notation.
The other main goal of the proposed methodology is the control and scheduling co-design which allows evaluating the performance and stability of controllers during their design. In fact, better performance can be achieved if the control system is designed with taking the resource constraints (implementation constraints) into account and if the real-time implementation and the scheduling are
251
BASIC LEVEL
Control unit (ex.: task)
META LEVEL
CU MoC aspect COM CU
Association (ex.: task dependency)
Communication mechanism (ex.: asynchronous)
functionnal aspect
Basic level
Meta level
Fig. 4. Component Structure (MoC Aspect) The constraints aspect enables to capture a major real-time constraints and properties. As shown in Fig. 5, the constraints imposed to a component are: • Period imposed to an operation. • Deadline imposed to an operation. • Latency between input and output interface. • Input rate of input interface.
Fig. 3. Brief Synopsis of the Proposed Metamodel A facet is an interconnection of hierarchical components. Each component is expressed in two levels of description: basic level and meta-level. The basic level corresponds to the functional aspect, which captures “what to do as operations”, and the meta-level corresponds to the non functional aspects, which capture “how to do these operations”.
The real-time properties of a component are: The basic level includes a component type, a declaration of the provided operations and the required ones, as well as the component interfaces.
Worst case execution time of an operation. Output rate of an output interface.
• •
The meta-level includes: • The Model of Computation Aspect (MoC aspect). • The Real-time Constraints Aspect.
MoC aspect
P Period D Deadline L Latency I Input rate
The MoC aspect is able to capture the various models of computation, existing in real-time embedded control systems. In (Hamouche, 2004), we have proposed the notion of a generic model of computation, which is a combination of two abstract concepts: an ontology concept and a communication mechanism concept. The ontology enables to unify the terminologies used in different languages and MoC. For instance, the concepts like state, task, reaction are unified into a control unit concept (see Fig. 4). The control units can be interlinked by an association concept, which enables to unifying concepts like transitions between states, dependency and priority between tasks, and so on. Based on these concepts, we have nowadays unified the discrete event, the discrete time and the finite state machine MoC.
I
P
D
W O L Constraints aspect
W Worst Case execution time O Output Rate
Fig. 5. Component Structure (Constraints Aspect) Relying on this metamodel, each facet can be described according to the corresponding domain concerns.
4.4 Facets Description In the control facet, the control law of the designed system is described with interconnected components, called control components. They have only one operation as functional aspect and they use the discrete event and the discrete time MoC. The operations are triggered by input events, which may occur according to an input rate constraint, corresponding to the sampling frequency of the system.
As for the communication mechanism concept, it enables to unify communication mechanisms used in major models of computation. It captures, in essence, synchronous and asynchronous communication mechanisms.
In the specification facet, the system is designed with interconnected software components, encapsulating
252
the operations inherited from the control design facet, and using the discrete event and the finite state machine MoC. A component may include one or more operations, triggered by input interfaces. This facet supports a constraints language, as a dedicated language, to specify real-time constraints, such as the rate of input and output interfaces, and the latency between input and output interfaces, corresponding to the response-time of the component. This constraints specification relies partly on sampling frequencies specified in the control facet.
establish the transformation rules. These rules are not defined aspect-by-aspect because the external models are usually monolithic descriptions. The aspects of a facet are firstly weaved and then are mapped to the target model.
5 MULTI-FACET DESIGN TOOL To implement and assess the feasibility of the proposed methodology, a new tool, providing a design framework, is under development. This tool is called MoDEST (Model-Driven Embedded System design Tool) which enables to create and manipulate facets graphically. By implementing some simple transformation rules, facets can interoperate and propagate any changes. By defining a simple metamodel of Scicos models and establishing some simple transformation rules, the tool can import Scicos discrete model into control facet.
In the implementation facet, the system realization is designed with a set of tasks, defined in the components inherited from the specification facet. For each component, there are one or more tasks which can encapsulate an inherited operation. The resultant tasks have constraints, such as period and deadline, inherited from the specification facet constraints. These constraints are evaluated by using pre-defined scheduling algorithms, in order to select the best scheduler that matches the system requirements.
On the other hand, the tool implements several realtime scheduling algorithms (Rate Monotonic, Earliest Deadline First …) in order to use them in the implementation facet. The results of scheduling are drawn graphically in chronogram and histogram format (see Fig. 7).
4.5 Facets Interoperability The proposed facets can interoperate in order to propagate facet changes from one to other. This interoperability relies on the proposed metamodel and uses the MDA approach. A facet is therefore considered as a PIM, which can be transformed to other one, defining a new facet. Transformation rules are established between the control facet and the specification facet, and also between the specification facet and the implementation facet. They consist of defining rules of similar aspects between different facets (see Fig. 6). Thus, the transformation process is done as per aspect basis rather than manipulating the facet in whole. The complexity of the transformation process is therefore reduced, the errors that could occur are avoided, and the model consistency is better.
This tool supports the code generation from the implementation facet. After weaving its aspects, this facet, considered as PIM, is transformed to platform specific codes, viewed as PSM. Presently, the tool support the generation of C applications executing in RTAI (Real-Time Application Interface), and the generation of real-time Java (RTSJ, 2007) applications. Facets
Fig. 6. Facets Interoperability Fig. 7. The Proposed Metamodel-based Tool The facets can also interoperate with an external model, considered as a PSM, in order to import its description or to export the facet description to third tools. This interoperability, reduced to PIM-PSM transformation, needs the definition of the metamodel of the external model, in order to
6. CONCLUSION In this paper, we have presented a methodology for design real-time embedded control systems. It
253
provides a metamodel which unifies the terminology and semantics used in the different design steps, in order to ensure the consistency of models. The methodology uses the component approach to improve the abstraction and the reusability of models. It uses the aspect-oriented approach to manipulate models regarding specific aspects and to facilitate the transformation of models. New tool called MoDEST, implementing this methodology, is in developing stage. Based on MDA approach, this tool enables us to do some simple model transformations and generate real-time applications.
Software implementation simulation to improve control laws design. In Proceedings of the European Congress SENSACT 2005, Paris, France. Lavarenne C., O. Seghrouchni, Y. Sorle and M. Sorine (1991). The SynDEx Software Environment for Real-Time Distributed Systems Design and Implementation. In Proceedings of the European Control Conference, Grenoble, France. Lee, E. A. and A. Sangiovanni-Vincentelli (1996). Comparing Models of Computation. In Proceedings of ICCAD, San Jose, USA. Mathworks. Matlab/Simulink home page: http://www.mathworks.com OMG. Object Management Group. Home page: http://www.omg.org. Ptolemy (2004). Ptolemy Project: Ptolemy II. Home page: http://ptolemy.eecs.berkeley.edu/. RTAI. Real-Time Application Interface. Home page: http://www.rtai.org/. RTJS. The Real-Time specification for Java. Home page: http://www.rtj.org Szyperski, C. (1999). Component software: beyond object-oriented programming. Addison-Wesley. Timmerman, M. (1999). RTOS market survey preliminary results. Real Time magazine.
The work is in progress to define formal transformation rules, to implement transformation processes, to bridge the tool with other common existing design tools by using the MDA approach, and to solve more complicated examples of real-time embedded systems.
7. REFERENCES Bézivin, J. and O. Gerbé (2001). Towards a precise definition of the OMG/MDA framework. In Proceedings of the Conference on Autonomous Software Engineering (ASE’01), San Diego, CA, USA. Cervin A. And B. Lincoln (2003). Jitterbug 1.1 Reference manual. Technical Report ISRN LUTFD2TFRT-7604-SE. Department of Automatic Control, Lund Institute of Technology, Sweden. De Niz, D. and P. H. Feiler (2007). Aspects in the Industry Standard AADL. Aspect-oriented software development. In Proceedings of the 10th international workshop on Aspect-oriented modelling. Vol. 209, Vancouver, Canada. Hamouche, R. (2004). Modélisation des systèmes embarqués à base de composant et d’aspect. PhD Thesis, University of Evry, France. Henriksson, D. and A. Cervin (2003). Truetime 1.1 Reference manual. Technical Report ISRN LUTFD2TFRT-7605-SE. Department of Automatic Control, Lund Institute of Technology, Sweden. Henriksson D., O. Redell, J. El-Khoury, M. Törngren and K.-E. Arzén (2005). Tools for Real-Time Control Systems Co-Design – A Survey. Internal Report, Department of Automatic Control, Lund Institute of Technology, Sweden. Inria. Scilab/Scicos tool. Home page: http://www.scicos.org/ Kiczales, G. et al. (1997). Aspect oriented programming, In Proceeding of ECOOP’97, Finland. Springer-Verlag LNCS 1241. Kocik, R. and Y. Sorel (2004). A methodology to reduce the design lifecycle of real-time embedded control systems. In Proceedings of the European Simulation and Modelling Conference (ESM’04), Paris, France. Kocik R., M. Ben Gaid and R. Hamouche (2005).
254
Abstract: Designing real-time embedded control systems follows usually a V-process and requires various languages and tools. Each language/tool provides a design methodology, and defines its own terminology and semantic. This lack of consistency leads usually to a disconnected design process where the transformation of models is usually performed manually. Thus, errors may be introduced in the models. Correcting these errors lengthens the design lifecycle and time to market. In this paper, we propose a new methodology which aims to fill the gaps due to the lack of consistency by unifying the terminologies and semantics used, and reduces the time spent in translation and debugging. This methodology does not propose a new global language which is far from each domain concerns and where the leaning curve is longer. The goal is rather to provide a multi-facet design using aspect and component approaches, and relying on an unified system metamodel in order to link the semantic differences between control and real-time computing languages and tools. Keywords: Real-time embedded control systems, design methodology, aspect, components, metamodeling, MDA.
1. INTRODUCTION
distributed architectures composed of processors (DSP, RISC) and specific integrated circuits (ASIC, FPGA).
Real-time embedded control systems are pervasive in different domains and industries, going from household appliances to aerospace domains. These systems, called controllers, are built with combination of software and hardware components. They have to keep under control the evolution of an other physical system, called plant, in order to ensure that it evolves towards a desired state, despite external disturbances. The controller observes permanently the plant evolution through sensors and is able to apply actions on the plant through actuators.
Designing theses systems follows usually a Vprocess, which allows building a system step by step according to top-down and then bottom-up design flow. A typical V-process for real-time embedded control systems design can be decomposed into three major steps (Kocik and Sorel, 2004): system control analysis, system specification and system real-time implementation. The result of each step is a model which is refined in the next one, until the implementation step.
Designing real-time embedded control systems tends to be more and more difficult due to the strong cost constraints and the growing complexity of the used software and hardware components. The software deals with different application domains (robotics, video, telecom…), implemented onto heterogeneous
The system control analysis, usually performed by control engineers, is a modelling step where the behaviour of plant and controller (control law) is described by a mathematical model, using dedicated languages and tools (like Matlab/Simulink (Mathworks) or Scilab/Scicos (Inria)), in order to
249
model and analyse the plant and synthesize the control law.
model of computation. It only facilitates simulation of fixed priority scheduling of tasks with constant execution times (Henriksson, et al., 2005). Another approach like AADL (Architecture analysis and Design Language) is emerged recently for a high level design and evaluation of the architecture of embedded systems. They are powerful but the complexity of models can be higher. In fact, the different real-time/embedded concerns (safety, security, real-time constraints, scalability, etc.) are mixed in the models. When one of the concerns of the model needs to be modified, manipulating the parts of the model related to that concern can prove to be challenging since these parts are mixed with the elements from other concerns (De Niz and Feiler, 2007).
The software specification is usually achieved by computer science engineers in order to implement the mathematical equations resulting from the modeling step, to capture the structure of the software, and to specify the high-level implementation constraints (input/output latency, jitter, etc.). The system real-time implementation, realized by computer science engineers, corresponds to writing the controller as real-time software that will be executed on the hardware, and meets the implementation constraints. Usually, this implementation is described as a set of tasks, functions with real-time execution constraints (period, priority, deadline, etc.) and properties (execution duration, memory footprint, etc.). These tasks are scheduled in order to guarantee they meet the specified real-time constraints (Timmerman, 1999).
This paper proposes an aspect-based methodology to design real-time embedded control systems with a “clean” separation of concerns. It is based on the aspect-oriented paradigm (Kiczales, et al., 1997) and the component-based approach (Szyperski, 1999) which are presented in the sections 2 and 3. The section 4 presents the goals and an overview of this methodology. A tool implementing the methodology is briefly presented in the section 5, before the conclusion.
Along this design process, several actors belonging to different domains (control, computer science, realtime…) are involved. They use domain-oriented method, languages and tools. Therefore, produced models at the different steps are heterogeneous. They differ mainly by the specified functionality, real-time constraints and models of computation (MoC) (Lee and Sangiovanni-Vincentelli, 1996).
2. ASPECT-ORIENTED APPROACH The aspect-oriented approach addresses the separation of functional aspects and non functional aspects in a system description, in order to manipulate the system regarding specific aspects, rather than in its whole. The benefits of this approach in real-time embedded control systems was demonstrated in (Hamouche, 2004; Hamouche, et al., 2001; Hamouche, et al., 2002), where aspects describe separately the system functionalities and its models of computation and real-time constraints. This separation leads to avoid the usual interweaving between those aspects. Thus, designing a system as a set of aspects ensures a clear description; give an extra dimension of system reusability and increases configuration capacities. Functionalities and realtime constraints will have a true separation. Reuse and configuration of system development is easier than in a monolithic design. Modifying any functionalities or constraints does not alter the whole system description; but involves a recompilation of this description.
This heterogeneity of models introduces lacks of consistency in the system design and leads usually to a disconnected design process where translations between the steps are needed. These translations are error-prone because they are usually performed manually by engineers. These errors may appear very early in the development process and be propagated into further steps. They can be only detected in the validation steps. Thus, correcting these errors needs numerous backtrackings (reiterations of V-cycle) in the design process, which lengthens the design lifecycle and time to market. Furthermore, the inconsistency of models may affect the implementation of the control system by disturbing its stability and reducing its performance (Kocik, et al., 2005). Nowadays, there are research challenges to define methodology and tools which reduce the design time and cost, and ensure the consistency of models from system level to implementation level. Tools that allow a control design and real-time design are quite a few. Ptolemy (Ptolemy, 2004), Jitterbug (Cervin and Lincoln, 2003), TrueTime (Henriksson and Cervin, 2003), SynDEx (Lavarenne, et al., 1991) are examples of such tools. Unfortunately, they are, in general, specialized on a certain aspect of the codesign problem or impose some restrictions (Henriksson, et al., 2005). Ptolemy tool, for instance, imposes some restrictions by the timed-multitasking
As shown in Fig. 1, the user only acts on the separated aspects, instead of the tangled code (ordinary description). Thanks to the aspect compiler, called weaver, that generates an ordinary description to be compiled by a standard compiler.
250
separated description Designer
functionnality Aspect 1 Aspect 2 Aspect 3
designed with the control performance in mind (Kocik and Sorel, 2004).
Tangled description weaver
to standard compiler
4.2 Multi-facet Design The proposed methodology defines a collaborative development approach for control and computer science engineers, where they work on a common platform, in multi-faceted fashion, to build a homogeneous design. According to the design process steps, three collateral facets are defined:
Fig. 1. Design Process of the Aspect-oriented Approach
3. COMPONENT-BASED APPROACH
• • •
The software component-based approach is increasingly used in different domains; it promotes a rapid construction of applications and models by assembling components. In (Szyperski, 1999), a component is defined as an autonomous unit of composition that is sufficiently self-contained. It can be deployed independently and is subject to composition by third parties. Every component needs to be well separated from its environment and the other components. It interacts with the environment or other components by a well specified interface. Using this notion of interface, a component declares what it provides and requires as services, relating to its environment. As a consequence, this approach improves the abstraction and the reusability of models.
Control facet Specification facet Implementation facet
Control engineers and computer science engineers act mainly on their own facets using a dedicated language which is closed to the corresponding domain concerned. As illustrated in Fig. 2, all languages and facets rely on a common metamodel which unifies the terminology and semantical differences between domains. The facets descriptions are therefore inwardly inter-linked. Designers can quickly observe and analyse changes made by one facet on the other.
Control facet language
Control facet
Spec. facet
4. METHODOLOGY OVERVIEW
Specification facet language
Metamodel
4.1 Methodology Goals
Impl. facet
The main goal is to define a methodology which unifies the design steps into a common approach and tool. In other words, this methodology has to handle the complexity and heterogeneity of models by filling the gap between the steps of the design process. The description of control modelling and its specification and implementation must be supported in a same approach in order to lead to a homogeneous design, and improve the model consistency and tractability along the design lifecycle. Improving the consistency of models leads to reduce the time spent in model translation and debugging, and then reduce the number of backtracking in design process. Another way to reduce the design lifecycle is to define modular models that are easily reusable and configurable.
Impl. facet language
Fig. 2. Design Facets
4.3 Metamodel for Control System Design The proposed methodology aims to follow the MDA (Model-Driven Architecture) design process (OMG ; Bézivin and Gerbé, 2001). It defines a metamodel as a description pattern which is able to capture the three facets description, and provides a support for interoperability between models, PIM (PlateformIndependent Model) or PSM (Platform-Specific Model) (OMG ; Bézivin and Gerbé, 2001). The brief synopsis of this pattern is drawn in Fig. 3 with UML notation.
The other main goal of the proposed methodology is the control and scheduling co-design which allows evaluating the performance and stability of controllers during their design. In fact, better performance can be achieved if the control system is designed with taking the resource constraints (implementation constraints) into account and if the real-time implementation and the scheduling are
251
BASIC LEVEL
Control unit (ex.: task)
META LEVEL
CU MoC aspect COM CU
Association (ex.: task dependency)
Communication mechanism (ex.: asynchronous)
functionnal aspect
Basic level
Meta level
Fig. 4. Component Structure (MoC Aspect) The constraints aspect enables to capture a major real-time constraints and properties. As shown in Fig. 5, the constraints imposed to a component are: • Period imposed to an operation. • Deadline imposed to an operation. • Latency between input and output interface. • Input rate of input interface.
Fig. 3. Brief Synopsis of the Proposed Metamodel A facet is an interconnection of hierarchical components. Each component is expressed in two levels of description: basic level and meta-level. The basic level corresponds to the functional aspect, which captures “what to do as operations”, and the meta-level corresponds to the non functional aspects, which capture “how to do these operations”.
The real-time properties of a component are: The basic level includes a component type, a declaration of the provided operations and the required ones, as well as the component interfaces.
Worst case execution time of an operation. Output rate of an output interface.
• •
The meta-level includes: • The Model of Computation Aspect (MoC aspect). • The Real-time Constraints Aspect.
MoC aspect
P Period D Deadline L Latency I Input rate
The MoC aspect is able to capture the various models of computation, existing in real-time embedded control systems. In (Hamouche, 2004), we have proposed the notion of a generic model of computation, which is a combination of two abstract concepts: an ontology concept and a communication mechanism concept. The ontology enables to unify the terminologies used in different languages and MoC. For instance, the concepts like state, task, reaction are unified into a control unit concept (see Fig. 4). The control units can be interlinked by an association concept, which enables to unifying concepts like transitions between states, dependency and priority between tasks, and so on. Based on these concepts, we have nowadays unified the discrete event, the discrete time and the finite state machine MoC.
I
P
D
W O L Constraints aspect
W Worst Case execution time O Output Rate
Fig. 5. Component Structure (Constraints Aspect) Relying on this metamodel, each facet can be described according to the corresponding domain concerns.
4.4 Facets Description In the control facet, the control law of the designed system is described with interconnected components, called control components. They have only one operation as functional aspect and they use the discrete event and the discrete time MoC. The operations are triggered by input events, which may occur according to an input rate constraint, corresponding to the sampling frequency of the system.
As for the communication mechanism concept, it enables to unify communication mechanisms used in major models of computation. It captures, in essence, synchronous and asynchronous communication mechanisms.
In the specification facet, the system is designed with interconnected software components, encapsulating
252
the operations inherited from the control design facet, and using the discrete event and the finite state machine MoC. A component may include one or more operations, triggered by input interfaces. This facet supports a constraints language, as a dedicated language, to specify real-time constraints, such as the rate of input and output interfaces, and the latency between input and output interfaces, corresponding to the response-time of the component. This constraints specification relies partly on sampling frequencies specified in the control facet.
establish the transformation rules. These rules are not defined aspect-by-aspect because the external models are usually monolithic descriptions. The aspects of a facet are firstly weaved and then are mapped to the target model.
5 MULTI-FACET DESIGN TOOL To implement and assess the feasibility of the proposed methodology, a new tool, providing a design framework, is under development. This tool is called MoDEST (Model-Driven Embedded System design Tool) which enables to create and manipulate facets graphically. By implementing some simple transformation rules, facets can interoperate and propagate any changes. By defining a simple metamodel of Scicos models and establishing some simple transformation rules, the tool can import Scicos discrete model into control facet.
In the implementation facet, the system realization is designed with a set of tasks, defined in the components inherited from the specification facet. For each component, there are one or more tasks which can encapsulate an inherited operation. The resultant tasks have constraints, such as period and deadline, inherited from the specification facet constraints. These constraints are evaluated by using pre-defined scheduling algorithms, in order to select the best scheduler that matches the system requirements.
On the other hand, the tool implements several realtime scheduling algorithms (Rate Monotonic, Earliest Deadline First …) in order to use them in the implementation facet. The results of scheduling are drawn graphically in chronogram and histogram format (see Fig. 7).
4.5 Facets Interoperability The proposed facets can interoperate in order to propagate facet changes from one to other. This interoperability relies on the proposed metamodel and uses the MDA approach. A facet is therefore considered as a PIM, which can be transformed to other one, defining a new facet. Transformation rules are established between the control facet and the specification facet, and also between the specification facet and the implementation facet. They consist of defining rules of similar aspects between different facets (see Fig. 6). Thus, the transformation process is done as per aspect basis rather than manipulating the facet in whole. The complexity of the transformation process is therefore reduced, the errors that could occur are avoided, and the model consistency is better.
This tool supports the code generation from the implementation facet. After weaving its aspects, this facet, considered as PIM, is transformed to platform specific codes, viewed as PSM. Presently, the tool support the generation of C applications executing in RTAI (Real-Time Application Interface), and the generation of real-time Java (RTSJ, 2007) applications. Facets
Fig. 6. Facets Interoperability Fig. 7. The Proposed Metamodel-based Tool The facets can also interoperate with an external model, considered as a PSM, in order to import its description or to export the facet description to third tools. This interoperability, reduced to PIM-PSM transformation, needs the definition of the metamodel of the external model, in order to
6. CONCLUSION In this paper, we have presented a methodology for design real-time embedded control systems. It
253
provides a metamodel which unifies the terminology and semantics used in the different design steps, in order to ensure the consistency of models. The methodology uses the component approach to improve the abstraction and the reusability of models. It uses the aspect-oriented approach to manipulate models regarding specific aspects and to facilitate the transformation of models. New tool called MoDEST, implementing this methodology, is in developing stage. Based on MDA approach, this tool enables us to do some simple model transformations and generate real-time applications.
Software implementation simulation to improve control laws design. In Proceedings of the European Congress SENSACT 2005, Paris, France. Lavarenne C., O. Seghrouchni, Y. Sorle and M. Sorine (1991). The SynDEx Software Environment for Real-Time Distributed Systems Design and Implementation. In Proceedings of the European Control Conference, Grenoble, France. Lee, E. A. and A. Sangiovanni-Vincentelli (1996). Comparing Models of Computation. In Proceedings of ICCAD, San Jose, USA. Mathworks. Matlab/Simulink home page: http://www.mathworks.com OMG. Object Management Group. Home page: http://www.omg.org. Ptolemy (2004). Ptolemy Project: Ptolemy II. Home page: http://ptolemy.eecs.berkeley.edu/. RTAI. Real-Time Application Interface. Home page: http://www.rtai.org/. RTJS. The Real-Time specification for Java. Home page: http://www.rtj.org Szyperski, C. (1999). Component software: beyond object-oriented programming. Addison-Wesley. Timmerman, M. (1999). RTOS market survey preliminary results. Real Time magazine.
The work is in progress to define formal transformation rules, to implement transformation processes, to bridge the tool with other common existing design tools by using the MDA approach, and to solve more complicated examples of real-time embedded systems.
7. REFERENCES Bézivin, J. and O. Gerbé (2001). Towards a precise definition of the OMG/MDA framework. In Proceedings of the Conference on Autonomous Software Engineering (ASE’01), San Diego, CA, USA. Cervin A. And B. Lincoln (2003). Jitterbug 1.1 Reference manual. Technical Report ISRN LUTFD2TFRT-7604-SE. Department of Automatic Control, Lund Institute of Technology, Sweden. De Niz, D. and P. H. Feiler (2007). Aspects in the Industry Standard AADL. Aspect-oriented software development. In Proceedings of the 10th international workshop on Aspect-oriented modelling. Vol. 209, Vancouver, Canada. Hamouche, R. (2004). Modélisation des systèmes embarqués à base de composant et d’aspect. PhD Thesis, University of Evry, France. Henriksson, D. and A. Cervin (2003). Truetime 1.1 Reference manual. Technical Report ISRN LUTFD2TFRT-7605-SE. Department of Automatic Control, Lund Institute of Technology, Sweden. Henriksson D., O. Redell, J. El-Khoury, M. Törngren and K.-E. Arzén (2005). Tools for Real-Time Control Systems Co-Design – A Survey. Internal Report, Department of Automatic Control, Lund Institute of Technology, Sweden. Inria. Scilab/Scicos tool. Home page: http://www.scicos.org/ Kiczales, G. et al. (1997). Aspect oriented programming, In Proceeding of ECOOP’97, Finland. Springer-Verlag LNCS 1241. Kocik, R. and Y. Sorel (2004). A methodology to reduce the design lifecycle of real-time embedded control systems. In Proceedings of the European Simulation and Modelling Conference (ESM’04), Paris, France. Kocik R., M. Ben Gaid and R. Hamouche (2005).
254