The choice of methods or design languages is a crucial phase in the development of systems and software, also for real time and embedded systems. An open question that remains in the design of these types of systems is to build a method, or to choose one among those existing, capable to cover the life cycle of a project, and particularly the development phases. This article contributes to answer the question, by proposing an approach based on a multi-criteria comparative study, of few languages and methods dedicated to the design of real time and embedded systems. The underlying objective of this work is to present to designers a wide range of approaches, and elements that can guide their choices. In order to reach this goal, we propose different comparison criteria. Each criterion is divided into sub-criteria, so that the designers can refine their choices according to the qualities they prefer and wish to have in the method or language. We also define a rating scale which is used to assess the retained languages and methods. The scores obtained from this assessment are presented in tables, one table per criterion, followed by a summary table giving the overall scores. Graphics built from these tables are provided and intend to facilitate the judgement and thus the choice of the designers.
The development of software systems usually starts with the requirements specification, and goes up to the executable code, passing by an architectural model of the system. This is done most of the time, starting from a context diagram. During design, the information contained in the context diagram and the requirements of the specification must be converted to produce the architecture model. A method is then needed to enable designers to move from a state of needs to a system architecture, through a decomposition of the problem, and the identification and specification of system components. This is also true for Real Time Embedded Systems (RTES). However the RTES have other features and constraints [
Different methods and languages have been developed for the analysis and design of real-time systems [
In the remainder of this article, the second section gives an overview of the works carried out by other authors on the comparison of approaches to design real-time and embedded systems, and positions our work compared to the latter. The third section specifies the criteria and rating scale used for qualitative and comparative analysis of approaches. The fourth section describes the system which serves as example to illustrate the operation of the different approaches presented. The fifth section is devoted to the presentation of the approaches highlighting the aspects related to the proposed criteria. The sixth section is dedicated to tables providing the ratings of the approaches according to the comparison criteria, to the corresponding graphics for a better appreciation of approaches. A discussion on the results obtained from this study followed by some perspectives concludes this article in Section 7.
Many works which have been done in the last decade focused on the study and comparison of languages, methods and design processes of Real Time and Embedded Systems (RTES). Some of them examine languages and methods for software architecture in general without restriction on RTES.
STAINES [
SHIRAISHI [
MEDVIDOVIC et al. [
BENDRAOU et al. [
CLEMENTS [
The works presented above deal with the comparison of approaches to design real-time systems, but some of them ( [
The goal of our work is to provide an objective comparison of approaches dedicated to the design of real-time and embedded systems, taking into account both modelling languages and design methods, including recent modelling languages (SysML, AADL, MARTE), and incorporating the criterion of dependability. In the next section, we present our comparison criteria and our rating scale.
For the comparison of approaches, we defined four criteria inspired by those proposed in [
-Usability: It reflects the ease of use of the method or language. This property seems important to us and even essential, because the approaches that are easy to use are generally preferred to those that are more complex. For each approach, we evaluate the ease of use from the following elements: clarity of its diagrams, types of notations used (textual, graphical, XML), the possibility to generate code from its models and existence of software tools (free and proprietary) supporting it.
-Compositionality: It refers to the way in which the notations of an approach are combined to describe a system. It also describes the structural composition, that is to say the capacity of the approaches to identify the different components of a system and to model the system hierarchically from these components (structural composition). This criterion is important because the structure obtained by composition of notations of the method will be used to build the final system. This criterion will take into account the following elements (sub-criteria): the means for system design (system engineering), the existence of a component model, capabilities of modelling and of decomposition/composition of a system (hierarchical decomposition). This criterion assumes the existence of techniques to refine the final design. This implies abstraction and information hiding.
-Availability of notations and techniques for real-time: This criterion evaluates approaches on their ability to take in charge and to manage real-time aspects. We defined a set of elements for this evaluation. Thus, this property takes into consideration: communication (exchange of messages, priority on messages, shared data, management of events and signals), concurrency management mechanisms, synchronization mechanisms (mutual exclusion, semaphore, monitor, rendez-vous) and time management (time quantification, management of simple or multiple clock). Special notations must be available in the approaches for the management of these elements.
-Dependability: Real-time systems are systems in which, in general, design errors and the failure to comply with temporal constraints can be fatal. An important criterion in the choice of design approaches, is then their ability to prevent this kind of failure, by providing means for error prevention and fault tolerance. The elements considered here are: the insurance of the system (formal notations and formal verification, modelling of errors), the management of quality of service (failure analysis, communication safety, security of interactions between components), the possibility to analyse models (schedulability and performance analysis) and simulation.
-The ability of modelling of software and hardware (codesign): in many systems, satisfaction of real-time constraints need to take into account both hardware and software aspects. In such cases, it is important to model not only the software, but also the hardware on which it will be deployed. Given its specificity, this criterion will not be detailed as the others. We simply specify which of the approaches discussed, take it into account. We give an analytical table specifying whether or not an approach takes it into account.
Regarding the mark scheme of approaches, we do more a qualitative comparison and thus specify if the property is taken into account (1) or not (0) by an approach. To compare the methods, a score will be assigned to each approach for each criterion, by simply summing the 0 and 1 obtained for each sub-criteria of the criterion.
This section presents the system that will serve as a basis to illustrate some aspects of the operation of the approaches considered in this article. This is a speed control system (cruise control) of vehicles, whose description is available in [
This system has the following inputs/outputs:
-cc_system_on_off: activated, this signal indicates that the speed control system would recognize the inputs by treating them appropriately.
-engine_status: activated, this signal indicates that the vehicle engine is switched on, the speed control system
is active only if the engine is running.
-brake_status: This signal is activated when the brake pedal is pressed, the cruise control will disengage when the brake pedal is pressed.
-resume: This signal contains the last speed maintained, it is only applicable if the cruise control is on.
-decrease_speed: This signal decreases the speed maintained, it is only applicable if the cruise control is on.
-increase_speed: This signal increases the speed maintained, it is only applicable if the cruise control system is running.
-set_speed: when it is generated, the current speed should be maintained.
-wheel_pulse: signal (pulse) sent to each wheel spin.
-clock: this signal sends a synchronization pulse (for example, every 10 milliseconds).
-throttle_setting: this signal corresponds to the position value for the accelerator setting.
An analysis and design method is a process whose objective is to allow to formalize the stages of development of a system, to make this development more faithful to the needs of the client. To do this, we start with an informal statement (need as expressed by the client, complemented by information obtained by soliciting experts of the field, such as future users of software), and the analysis of the potential existing (that is to say, how the process to design is currently implemented at the customer). In a method, one uses one or more modelling languages for symbolic or schematic representation of the various models produced in the method, tools and one applies an approach. In other words, a method is a set of one or more modelling languages, of a process or approach to drive the development and tools that support it.
In this section, we present design approaches (languages and methods) of real-time systems by giving for each of them: a brief presentation; the ease of use it offers (take in hand, the availability of tools supporting them, concepts and notations available for the representation of systems); the means provided to compose the system from structural elements, and produce the architecture; elements provided for real-time aspects of the system; dependability mechanisms offered by the approach; an illustration of its use through the application to the example chosen. The approaches presented in this section have been chosen to be a representative subset of design methods and modelling languages of real-time and embedded systems. These approaches are also those most studied in the literature. The section is organized into two sub-sections: the first presents methods and the second is devoted to modelling languages for real-time systems.
1) Presentation
CORE method [
2) Usability
CORE is more specialized for the needs analysis phase. As such, it provides a facility for the understanding of the system to be developed. It makes extensive use of the concept of point of view and allows developers to better understand the system by studying it under different angles. CORE defines steps for requirements specification: for each step, the activities to be undertaken are described, as well as controls to perform. It offers a graphical notation that supports it. This is a fairly simple notation and which can be applied to different aspects in the system description. It also provides a consistent formal interpretation of its graphical and mathematical notations. This allows to graphical specifications to be combined easily with detailed specifications, which are given in mathematical and textual notations. Finally, CORE describes the required behaviour in the form of mathematical relationships between the quantities of the environment, it makes it possible to specify requirements without providing unnecessary details of design. This is a mathematically rigorous method. Thus, it supports precise requirements, unambiguous, complete and consistent. The results of the analyst’s work are recorded in the CORE diagrammatic notation for which a set of rules is laid down. This notation will be accessible to most clients. Its diagrams are classified into two categories: dynamic diagrams that represent the time flows and the connections between ordered temporal elements and static diagrams that show the hierarchical structure linking the dynamic diagrams. CORE does not provide a textual language to describe the developed systems. It offers a four-step approach: 1) definition of the problem, 2) definition of points of views of the requirement (life cycle, environment, operator, reliability), 3) development of detailed models for each point of view, 4) combination of the different points of views in a compound model. There are a few tools such as CORE, which is a complete modelling environment designed for engineering of complex systems. It allows requirements management to ensure that we capture accurately the needs of customers, it allows to build fully executable behaviour models. There is also PSL/PSA (Problem Statement Language/Problem Statement Analyzer), which is a computer-aided technique for structured documentation and analysis of information processing systems; it is a powerful requirements modelling toolkit.
3) Compositionality
It is possible to achieve a structural composition of the system from its notations; Indeed, CORE offers two ways of decomposing a system: the data decomposition and the actions decomposition. Furthermore, static diagrams provide a structural view of the system. Its diagrams are quite understandable and it offers a textual interpretation of diagrams (static and dynamic). CORE analysis proceeds iteratively, each iteration decomposing the viewpoints at a certain level. In this way a top-down expansion of the viewpoint hierarchy is produced. (this is similar to the viewpoint models of SADT). It is the responsibility of an experienced analyst to extract from all the parties concerned the relevant viewpoints, at each step, and the relationships they have with each other and with the hierarchy of which they form part. CORE defines how the analyst should propose, define and confirm these relevant viewpoints. The “confirmation” of viewpoints means their successful combination into a coherent system, the addition of reliability actions and data to the combined viewpoints, and their acceptance by the users [
4) Existence of notations dedicated to real-time
For each point of view, CORE allows to define various types of characteristic information. Thus one can define actions (send a message, execute an instruction, etc.), time-based events which trigger these actions. This allows to support the analysis of some real-time aspects.
5) Dependability
As we mentioned above, CORE provides a consistent formal interpretation of graphical and mathematical notations. This can help to make a formal analysis of models so specified. CORE is also seen as a procedure for determining the functional requirements of a system, and develop the functional specifications of this one. It determines the requirements from different points of view, including that of reliability. Thus, the specifications produced by CORE from requirements related to reliability, take into account the actions to be executed by the system in case of failure, and under different conditions.
6) Illustration example
The central concept of CORE is the viewpoint and the associated representation known as the viewpoint hierarchy. Viewpoints are not only concerned with human perspectives. Viewpoints can be associated with:
・ the system’s stakeholders;
・ the system’s operating environment;
・ the system’s domain.
Thus, a viewpoint can be a person, role or organization that has a view about an intended system.
When used for system requirements, the viewpoints can also represent the intended system, its subsystems and systems that exist within the environment of the system that may influence what the system must do. The viewpoints are organized in a hierarchy to provide a scope and also to guide the analysis process [
First, we must identify viewpoints. For example, on Cruise Control System, here’s a possible list of initial views that can be obtained after a brainstorming.
Having produced a list of potential viewpoints, they are organized into a hierarchy by grouping related candidates. The figure below shows a partial hierarchy of viewpoints for the Cruise control system.
7) Strengths and weaknesses
CORE is adapted to the requirements specification of a system. It expresses specification with the help of informal notations such as block diagrams. But CORE is a mathematically rigorous method, which also provides a formal interpretation of its graphical and mathematics notations. This approach could be used in conjunction with object-oriented analysis. It is supported by a fairly simple diagrammatic notation, but that allows to represent several essential points of views of the required system configuration. The main limitations of CORE are: 1) The real-time aspects, the concurrency management and the synchronization are not clearly defined; 2) It is inappropriate for the architectural design; 3) It is rigid and relies on too many steps; 4) For anything but very small projects, manual support of CORE is likely to be unwieldy and an automated tool such as PSL/PSA or SDS/RSRE is required.
1) Presentation
JSD [
2) Usability
JSD provides a graphical notation and its sequential processes are documented by a pseudo code, called structure text. It is a linear method. Therefore, its steps are simple to follow. Three basic principles underpin the functioning of the JSD method:
-We must begin the development by describing and modelling the real world, rather than specifying or structure the functions performed by the system;
-An adequate model of a time-ordered world must itself be ordered in time, the main aim being to match the progression of real world to the one of the system that models it;
-The implementation of the system is based on the translation of its specification into a set of effective processes. These processes must be designed so that it is possible to do them operate on the software and hardware available.
JSD has three phases in its implementation [
The modelling phase: In this phase, the designer identifies the entities of the system, the actions that they carry out, the order of execution of actions in the life cycle of entities, and attributes of entities and actions. A structure diagram of entities is produced, which gives a full description of the system and its organization.
Network phase: At this stage a model of the whole system is developed and represented in form of diagram of specification also called network diagram. The network diagram shows the processes and communications between them. The communication between processes is in the form of data streams or messages through state vectors. So this phase focuses on defining the system functionalities. Each entity identified in the previous phase, becomes a process in the network diagram. The programs which are external to the system are added to the diagram later. The whole system is described using these network diagrams, which are complemented by the description of the data and the connections between the processes and programs.
The implementation phase: During this phase, the JSD specification, composed potentially of a very large number of processes, is translated into a system implementation diagram which is directly executable. The latter presents the system as a process scheduling calling the modules that implement the system.
There are a few tools to build JSD diagrams; we can mention:
-Smartdraw: which provides an editor to build the structure diagram of entities (from the modelling phase) and network diagrams (the result of the network phase). This tool is not free.
-Jackson Workbench: is a suite of tools making it possible to build, among others, the JSD diagrams.
-We also have JSD Network Editor, which supports the JSD method for the design of software systems. This editor offers a wide visual interface that allows the specification and implementation of JSD network diagrams.
3) Compositionality
The system is built gradually from its components. In the modelling phase, the system is broken down into its various entities; then the actions realized by these entities are specified. The various components of the system thus obtained are grouped in a structures diagram of the entities.
4) Existence of notations dedicated to real-time
The method provides the following possibilities:
Communication by message: in the network diagram, the communications in the system through connections by data stream are done by sending messages.
Support for special event type: JSD uses messages called time markers that act as data flow but contain synchronization information. They are roughly merged with other data streams to monitor the arrival of messages and the moment of execution of processes. They are used to trigger actions within the processes, start and stop processes and generally help to process synchronization.
5) Dependability
JSD allows to define a permissible delay between the sending and the reception of a message, which ensures some security in communication.
6) Illustration example
JSD method provides the following graphical notations for systems modeling (see
The process represents a sequential thread of execution; streams (data stream) which are infinite buffers allow not only communication between two processes, but also to communicate external events to a system. A process can write in a state vector, if it is the owner (source of the state vector) or simply read its contents otherwise.
7) Strengths and weaknesses
The application of JSD to design of real-time systems has strengths, but also limitations [
Strengths:
-The emphasis on modelling of real-world entities is a theme that has been followed by several object- oriented analysis and design methods;
-The modelling of each entity of the real world, focusing on the sequence of events experienced by the entity is particularly relevant in the real-time systems design;
-The concurrent treatment is an aspect which is at the heart of the method.
-Clear steps are planned to spend from a JSD design to an implementation.
Weaknesses:
-Since the structure of entities and therefore, the models of structures handling event sequences almost faithfully represent the real world, relatively minor changes in the real world can affect the software structure, which could make maintainability more difficult and is a potential barrier to reuse;
-JSD does not focus on data abstraction and information hiding, which could have a negative impact on maintainability;
-JSD uses a structure diagram of entities to represent systems, while it is often easier to model the events sequence in a complex entity with a state-transitions diagram; especially in real-time systems where complex
events sequence are not uncommon.
1) Presentation
RTSAD [
YSM is based on the classic DFD and structured methods used for designing traditional data. This method has been adapted and combined with many real-time design approaches. YSM has been developed and improved over the years and many modern tools support its notations.
2) Usability
These methods use two main types of diagrams: the Data Flow Diagrams (DFD) and the Control Flow Diagrams (CFD), which in principle can be combined. They are quite well known diagrams, reflecting the take on hand fairly quick and easy of these methods. In addition to the DFD, the CFD and state transition diagrams, there are other notations intended to provide more detailed information on the design. Among them, there are entity-relationship diagrams and structure diagrams. These, though important, are less specific to the definition of the behaviour of real-time systems.
A particularity of YSM compared to the other two, is that it can be used in conjunction with diagrams like the PEM (Processor Environment Model) [
The RTSAD method provides an approach structured in five steps: defining a context diagram, decomposition of the system into a data stream or control flow, building of a control transformation or control specification, process specification, and development of a data dictionary. YSM as for it is based on the conventional DFD and structured methods used in traditional conceptions of data. Regarding the DARTS method [
It is possible to derive the program code from the decomposition model of the system and the diagram of tasks architecture.
An example of tool is the SELECT Yourdon, which operates under the Microsoft Windows environment, and allows people with a small budget to design and document their products. It supports data streams and controls streams. It also allows the design of state transition diagrams and allows to create a complete data dictionary.
3) Compositionality
The use of YSM begins with a high-level description of the system, which breaks down until lower levels (simple) with complete specification of the program. In RTSAD method, the system is decomposed into a stream of data or controls. It is an approach that consists of breaking down a system into its components through a DFD or a CFD. In DARTS, the second step of the method consists in decomposing the system into subsystems and to identify interfaces of these latter. This decomposition is done until the concurrent tasks of the system are obtained.
4) Existence of notations dedicated to real-time
In these methods we have the notions of control flows (signals or interruptions) and of control processes (processes whose only job is to coordinate and synchronize the activities of other elements of the DFD). The DARTS method particularly includes concurrency in the design, and allows the expression of communication and synchronization mechanisms between the units of concurrency. There is also a concurrent version of DARTS called CODARTS [
5) Dependability
These three methods do not define any technique of dependability, if we do refer to the elements chosen in this work to characterize this aspect.
6) Illustration example
These methods use the following symbols for the construction of their different diagrams:
We illustrate the use of these notations in the diagram of
Works have been done on the integration of temporal aspects in the DFD. Thus, new concepts and notations have been defined to distinguish: three types of streams of events (signal, activation, deactivation), and two types of storage (data storage and buffer).
The works of [
In addition to these DFD techniques, the DARTS method uses other notations that we will present in the section related to ADARTS.
7) Strengths and weaknesses
For these three methods, the main advantage is the use of a high level of structured analysis of data. They are easy to take in hand, because they use fairly well known diagrams (data flow diagram and control flow diagram). They present some limitations: 1) They are unsuitable for prototyping. 2) The steps must be carried out sequentially for a successful implementation. 3) It is difficult to control the time required for the full implementation of the system. In addition to these limits, CODARTS presents few others: it is designed primarily for the ADA language, the notations used are not easy to understand, it is complex to use and offers a limited number of views in the system design.
1) Presentation
MASCOT [
2) Usability
MASCOT is based on a form of functional and structural decomposition, which is particularly suitable for use in the development of large distributed real-time embedded systems for data processing. The emphasis is on the word “large”: a large number of people involved in the development, a large amount of code to write, a large number of requirements to be taken into account at the same time, a wide variety or quantity of hardware resources, a project whose development extends over a long period. Of course, all these measures of sizes are relative. The method provides a design language and a graphical notation, and a process of conceptual derivation. MASCOT models are stated in terms of a set of text modules and diagrams that support the principles of data flow on which the method is founded. These diagrams are used to show the decomposition of a system into subsystems consisting of concurrent tasks. The interfaces between the tasks are in the form of channels (message queues) and pools (information hiding modules). There is a textual language to describe the graphic representa- tion. The main steps of this method are: 1) Fully describe the internal functions of the system, and its relations with the outside. This is done through the network diagram. 2) The first network is decomposed into components of lower level, 3) the components are encoded in terms of algorithms and data structures.
In terms of tools, we have the development environment of MASCOT version 3.1, which was defined in terms of a set of functions to control the progressive capture of a design.
3) Compositionality
Modular as its name suggests, the cornerstone of the method is a particular formalism by which a complex software can be broken down into a number of smaller components that interact with each other, and this decomposition process can be repeated at any depth required to produce a manageable development task.
4) Existence of Notations Dedicated to Real-Time
MASCOT provides the ability to use certain communication protocols [
5) Dependability
MASCOT does not define any technique of dependability, if we refer only to the elements chosen in this work to characterize this criterion.
6) Illustration example
MASCOT is characterized by two types of elementary basic components: activity (a single thread of execution), which is an active element, and IDA (intercommunication data area) which is a passive element. IDAs are interconnected to form a data flow diagram.
Connection to physical entities (represented by a grey rectangle) is made by dashed lines, which indicate what software unit is responsible of which hardware.
MASCOT uses a number of concepts and notations for systems modelling, including:
-Activity: A rectangle with rounded edges and often a circle
-IDA: A rectangle or a rectangle with rounded side.
-Window: A small full rectangle. This is a IDA point, marking the passive end of a connection of data flow.
-The port: A small full circle, this is a point in the activity that marks the active end of a connection of data flows. Each port expresses a requirement for access to data of the IDA, which must be satisfied when the port is connected to a window of IDA.
-The path: An arrow, this is a connection between a port and a window. Only one path must be connected to a port, but several paths can be connected to a window.
-The physical entity: A grey rectangle.
The name of an activity or an IDA is placed within the concept, while the name of the instantiation thereof is located outside of its representation.
On
7) Strengths and weaknesses
One of the strengths of MASCOT is that it relies on the Ada language and as such, it benefits of its advantages in terms of design of large systems, of high level of abstraction, etc. The fact to be based on a form of functional and structural decomposition makes it well suited to the development of large distributed real-time embedded systems for data processing. MASCOT has some limits, among which: it does not directly support the requirements analysis (needs) and goes directly into building models; there are not many tools supporting it; it is not suitable for prototyping or for rapid application development; its use greatly increases development costs.
1) Presentation
ADARTS [
2) Usability
ADARTS provides a graphical representation and textual notations for modelling real-time systems. The stage of the structured design in DARTS is replaced by the one of modules structuring, with concealment of information provided by Ada. It can be considered as similar to DARTS, but with some improvements such as abstraction and decomposition. Another version of DARTS also exists and is intended for the design of distributed real-time applications: this is DARTS/DA. It proposes an approach based on five steps: development of an environmental and behavioural model (development of a context diagram, of a states-transition diagram, of data
flows and control flows diagrams, of a data dictionary and production of a mini specification), structuring the system in concurrent tasks (production of a tasks architecture diagram and specification of the behaviour of each task), structuring of system as information’s abstraction modules (construction of the system architecture schema), development of a design based on Ada architecture (only required for the implementation in Ada), definition of Ada components interfaces (only required for the implementation in Ada, here a specification of Ada packages is produced). This method is supported by tools such as IBM Rational Rhapsody published by IBM, which is a model-driven development environment, very interesting for systems engineers and software developers of real time and embedded systems; it allows to create many Ada compatible diagrams and to generate the corresponding Ada code, but also C, C++, Java and C# code.
3) Compositionality
Decomposition is one of the improvements brought by ADARTS to DARTS [
4) Existence of notations dedicated to real-time
ADARTS was developed to extend concurrent task aspects of DARTS, putting also emphasis on the information hiding. ADARTS naturally includes real-time characteristics of DARTS presented above. Another evolution of DARTS called DARTS/DA has been proposed for the design of distributed real-time applications.
5) Dependability
ADARTS does not define any dependability technique, if we refer only to the elements chosen in this work to characterize this aspect.
6) Illustration example
ADARTS uses DARTS notations. It includes interprocess communication.
7) Strengths and weaknesses
A key strength of ADARTS is the maintainable and reusable character of designs it produces, because it uses
a higher information abstraction than DARTS. In addition, the ADARTS diagrams are fairly well reproducible [
1) Presentation
ROOM [
2) Usability
ROOM defines a specification of the system at two distinct levels, but formally linked. The top level, called schematic level, is used to specify the architectural aspects of a system. The lower level, called detail level, defines the details of a finer implementation. This method allows the use of languages such as C++ [
3) Compositionality
ROOM offers the possibility to break down a system into subsystems. Using these decomposition functions, complex actors can be decomposed into aggregations of more elementary actors. ROOM imposes no limit on the number of decomposition levels, which allows for arbitrarily complex architectures specification. A hierarchy defined in the ROOMcharts allows a state to contain a states machine. This makes it possible to solve a complex problem gradually, by approaching one abstraction level at a time.
4) Existence of notations dedicated to real-time
ROOM focuses its schematic language on a single domain: real-time distributed systems, characterized by events or reactive behaviour. This means that all proposed notations are specific to this field. It handles events by sending messages. The arrival of an event is signalled by the arrival of a message to an object. Sending messages is useful for modelling the asynchronous nature of the events, as well as for the treatment of distributed systems where shared memory may not exist. Communications based on synchronous and asynchronous messages are supported.
5) Dependability
The ROOM method allows to define models which will be simulated by its ObjecTime tool. This allows to do a sort of validation a priori of models before their implementation.
6) Illustration example
ROOM uses the following concepts:
-Actor: This is the primary structural element of ROOM. It is a competitor object responsible for performing specific functions.
-Port: Enables communication between actors and other objects.
-Connection: Establishes a communication link between two ports.
For the representation of complex systems, ROOM combines one or more different types of objects in an aggregation of functions. In ROOM, this is represented by three mechanisms of primary composition: binding, layer connection and the containment relationship.
An actor is represented as shown in
P1 is a provided Port (signal transmitter) and P2 is a required port (signal receiver).
We show in
The system is then defined by seven actors: one for the system speed control (cruise control system) and one for each component with which the cruise controller interacts to perform its functions.
The behaviour of each actor is given by a statechart diagram.
We give thereafter the internal structure of the control system itself. This is what is shown in
It is possible to define temporal constraints on transactions between system components. For example,
On this schema, we define a time of 100 ms between the time where the user enters his speed (through the lever), and the one where the new acceleration data are issued by the system.
7) Strengths and weaknesses
ROOM uses a “run-to-completion” model event processing. This simply means that messages are processed one at a time; once the management of a message is initiated by an actor, and until it is completed, no other message is processed by the actor (which implies to put messages in queue at interfaces). The advantage of this
approach is that it provides the automatic mutual exclusion of event handlers and, therefore considerably simplifies the behaviour specification. It has some limitations among which: it requires a special tool called “ObjecTime”, it has a limited number of diagrams, which show only certain views of the system: the static view with the level of architectural specification and the dynamic view with ROOMcharts and details for the implementation. Diagrams that it offers do not allow a good conduct of initial requirement engineering.
1) Presentation
HOOD [
code generation of distributed real-time software. HOOD can be used for prototyping. The idea is to identify objects in a hierarchical parent-child relationship, and their operations. A graphic description of the system is produced in a data/controls flow diagram.
2) Usability
HOOD provides a graphical notation, with fairly clear diagrams and easy to understand. HRT-HOOD version has a textual notation. With HOOD, a project consists of a set of main modelling units called “Designs”. A “Design” may lead either to a completely autonomous software application (executable file), or a library of linkable software entities (functions, data types, classes, …). Moreover, dedicated categories of models have been defined to support reusable parametric components (generic) and software partitioning of distributed systems (virtual nodes). Each HOOD model (design) is the root of a hierarchy of components which are usually built in a top-down approach that directs the architectural design phase of the software development process. HOOD applies the client-server communication between interacting components. Accordingly, all these interactions are implemented by function calls. In particular, the standard rules of HOOD recommend to prohibit direct access to shared variables and to implement all the data stream by subroutines calls. Furthermore, in order to ensure a good management of the development team, of the modular deployment and maintenance of applications, HOOD imposes a strict visibility of rules easily controlled at the design level. The life cycle proposed by HOOD is fairly standard and includes: requirements definition (specification of functional and non-functional requirements of the system is produced), architectural design (a high-level description of the proposed system is developed), detailed design (the design of the complete system is specified), coding, testing (system efficiency is tested).
There are tools supporting HOOD, among which STOOD, which is a tool produced and marketed by the Ellidiss Technologies company. STOOD offers many features: it makes it possible to ensure an update of traceability between the system and the software models and the initial requirements, which may be imported from text files or other tools; It provides a graphical editor for building of architecture models of the software and its environment (libraries, runtime platform, …); it also allows detailed design, checking a design, integrating analysis tools, automatic code generation in Ada, C and C++, and generating design documentation.
3) Compositionality
As mentioned above, the HOOD method is based on system decomposition into a components hierarchy describing the system. Thus the objects are identified, and for each object, its children objects are identified, and so on. It guarantees a low coupling between modules (components) of a system, which is a necessary factor for system components reusability and maintainability.
4) Existence of notations dedicated to real-time
HOOD modelling structures include active components to support concurrent control flow in same software. Communication protocols between the active components are defined and include synchronous (low and high) and asynchronous paradigms. A specific version of the HOOD method called HRT-HOOD (Hard Real-Time HOOD) [
5) Dependability
The decomposition rules of the method ensure the obtaining of a final design onto which temporal properties analysis can be performed. Indeed, in HRT-HOOD, object attributes were added to the terminal objects, to enable them to be annotated with their real-time characteristics (time, period, worst case execution time). This provides the possibility to perform analysis of non-functional properties on the resulting models (scheduling analysis, performance analysis, etc.).
6) Example of illustration
A HOOD object is defined by a name, a set of operations, a tree of children objects, a tree of implementations in children operations.
The diagram of
Since we are interested in the speed control subsystem, it is question of giving its internal structure. This is done by considering the Cruise Control object in
This representation is given in
7) Strengths and weaknesses
HOOD has a fairly complete development process that goes up to the code generation of distributed real-time software. Its charts are easy to understand. HOOD allows to define generic components, configurable and there- fore reusable. A HOOD design defines loosely coupled modules, which ensures system maintainability and reusability of its components. In addition, HOOD4 version significantly improved the method by taking into account the true object-oriented, providing opportunities for code generation in C++ and Ada95. HOOD has limitations: it does not distinguish data flows between objects from events signals, it is not so simple to use, and it uses a single type of diagram.
This section has dealt with design methods. The following subsection is devoted to the modelling languages used in the design of real time and embedded systems.
1) Presentation
UML [
2) Usability
UML is not a method (i.e. a normative description of the modelling steps), but a graphical language for representing various aspects of a system. It provides a set of graphical notations grouped into charts specific to each aspect of a system. Each graphical notation has an associated text which explains its content. UML allows to see the system in 2 different angles called views: a static view and a behavioural view. Although not being a method [
3) Compositionality
UML version 2, provides the composite structure diagram which makes it possible to represent a system by its components, and to provide the internal structure of each component. This component-based model makes it possible to obtain step by step the hierarchical architecture of a system.
4) Notations dedicated to real time
UML, through some of its diagrams such as the diagram of sequences, of activities, of state transitions (temporal events) and of composite structures, allows somehow, to manage real time aspects. It is possible to perform temporal specifications on a sequence diagram, by specifying for example the time elapsed between two messages sent [
5) Dependability
The notations provided by UML are not formal, but with the OCL language, it is possible to define on UML diagrams, constraints which will be formally checked.
6) Example of illustration
The different graphical notations used in the UML language are summarised by diagrams. In its second release, UML has 13 diagrams. The details on the latter are available in [
-Component: element of the system which specifies its interactions with the outside through the definition of its interfaces (provided or required);
-Port: point of interaction of the component. It is associated to an interface of operations (in provided or required mode);
-Connector: it is either of delegation type if it links a port of a component to a port of one of its subcomponents (one talks about composite component), or of type assembling if it links an interface of a component to that of another.
We use these concepts to represent the architecture of the speed controller, given by the diagram in
7) Strengths and weaknesses
UML is easy to handle and offers a wide range of diagrams for modelling almost all aspects and views of a system. The availability of a large number of free tools makes it accessible to all users. It is now used in the vast majority of companies developing software for the purpose not only of documentation and analysis, but increasingly for productive purposes (automatic or semi-automatic generation of code) or testing. In addition, UML takes into account new (graphical) notations of extended stereotypes, it requires less skill in language design and it reuses languages infrastructures (tools, specification).
UML has some limitations: 1) studies show that maintaining UML diagrams can be a complex process, 2) Although OCL allows to define constraints on UML diagrams, it lacks a formal definition of the concept of time and the degree of formal verification of its diagrams remains low, 3) the same things can be modelled from different perspectives, and all could be correct, which means it lacks a bit of consistency, 4) in UML we focus more on modelling the system rather than on the process of software development. This implies that UML should be used in a structure like USDP (Unified Software Development Process) created by the OMG and
COMET (Concurrent Object Modelling architectural design method) [
1) Presentation
UML-RT [
2) Usability
As UML, UML-RT provides a graphical notation, but defines new concepts compared to UML; we have:
-Capsules: describe the complex components of the system that can interact with their environment. Their interaction with the environment is managed through ports. The ports are the only means of interaction with the environment. They are often associated with protocols that regulate the flow of information through a port. Ports can be public or private. Public ports must be located at the boundary of a capsule. The connectors are used to interconnect two or more ports of capsules and thus describe the communication relationships between capsules.
-Protocol: In UML-RT it is a set of signals sent and received along the connectors.
The explicit representation of the ports, protocols and connectors make possible the construction of architectural models from a collection of capsules. For the representation of the system architecture, a collaboration diagram of capsules is defined and describes the system components and how they are connected. To describe how the capsules react to messages received or sent through their ports, UML-RT uses the UML state diagram.
There are a few tools supporting UML-RT, such as RoseRT (RoseRT CASE tool). There is also for UML-RT, a runtime framework called TargetRTS (Target Run Time System) used as virtual machine supporting the execution model defined by UML-RT. It runs on top of a SE-RT (Real Time Operating System) to hide details specific to the provider of the runtime platform and to present a uniform API for the engineer designing the system.
3) Compositionality
The capsules can be hierarchically structured, by using a number of subcapsules which may themselves contain subcapsules.
4) Notations dedicated to real-time
UML-RT enriches the UML sequence diagram by adding timing requirements (the execution time of a sequence, the deadline, etc.), for example the rate at which the speed controller must perform its control loop [
5) Dependability
UML-RT is a UML extension, so it naturally supports the OCL language, which allows to define formally verifiable constraints on a model.
6) Example of illustration
In UML-RT the different concepts are represented as follows:
-The capsule by a box labelled with the name of the capsule;
-The port by a small empty or full square on the edge of the capsule;
-The connector by a line between two ports.
7) Strengths and weaknesses
In addition to the advantages of UML, UML-RT provides elements for modelling real-time aspects. In particular, it adds the concept of capsule which is a component that can interact with its environment. It also includes
all the modelling capabilities of ROOM. However UML-RT has some limitations: it is not widely used, there are very few tools supporting it, it lacks a precise semantics. Another disadvantage is that it is restricted to binary communication links between components.
1) Presentation: AADL version 2.0 standard
AADL (Architecture Analysis and Design Language) [
2) Usability
AADL is standardised by the SAE (Society of Automotive Engineers). It defines the architecture of the system as a set of interconnected components. The modelling of AADL components consists in describing interfaces, implementations and properties of the components. It has a graphical notation and a textual notation. There are tools that make it possible to obtain an XML notation of model from these notations, but also to go from a type of notation to another. AADL is extensible: it is possible to use other languages to define AADL annexes. Moreover, the standard provides annexes that make it possible to specify the behaviour of an application, to model data, to model errors and guidelines for code generation. Architectures definition is based on the components and the interactions between them.
There exists several tools [
Osate provides AADL support for Eclipse. In the first version, Osate supports the first release of AADL. The second version is available since august 2011 and it supports AADL r2. Cheddar is a tool for real-time scheduling analysis which works typically with STOOD and AADL Inspector. Ocarina is able to load an AADL r1 or r2 project, to run analysis and to generate code from the model. Topcased is an environment for eclipse including a generator of graphical editor.
Concerning the commercialised tools, Stood, developed by the Ellidiss company, is used to model and design embedded software. It supports three graphical notations: HOOD, UML and AADL. AADL inspector is a light tool for AADL project analysis, it offers a set of analysis plug-ins which can be extended with external rule analysers. Taste is a set of tools dedicated to the development of embedded real-time systems. It is developed by the European Space Agency and partners of the spatial industry.
3) Compositionality
The AADL language allows the specification of sub-components or subcomponents tables contained in a component. Thus, we can describe hierarchical compositions of components1 or model a complete hierarchical system that is to say get a full view (in terms of structural view) of all instances that make up a system. To do this, AADL defines components and interactions between them.
In AADL, a component consists of two parts: an interface (component type) that defines the services provided and required through which other components can interact, and one or several implementations (component implementation) that specify the component internal structure. The AADL components are grouped into three main categories:
-Software components: Data (data structures), Subprogram and Subprogram group (code of subprogram and library), Thread and Thread Group (schedulable execution unit), Process (virtual address space);
-The components of the execution platform (hardware): Processor (schedule and execute a thread), Virtual Processor (virtual machine, for example), Memory (represents storage components), Bus and Virtual Bus (respectively communication channels and communication protocols), Device (entity external to the system);
-System components: System is the only component of the family and models a hierarchical assembly of software and hardware components.
The interactions between components are done by “features” (these are communications points) specified in their interfaces and “connections” specified in their implementations:
-The features: The AADL language defines three categories of features: port, parameter (parameters of subprograms) and subcomponent access. Ports are communication interfaces for exchanging data and events between components. They can be of three types: data port, event port and event data port. For each type of port, communication can be in (incoming), out (outgoing) or in out (incoming/outgoing). The concept of sub-program can be used for the representation of mechanisms such as locks to protect shared data.
-Connections: Connections in AADL are made in the connections section of the implementation part of the component (component implementation). The language allows to connect the components together by commu- nication points specified in their respective interfaces. There are four types of connections in AADL: port con- nections (type port), connections of parameters (type parameter), connections of access to shared components (type data access, bus access, subprogram access, virtual bus access) and connections of groups of features (type feature group). Other concepts are available in [
4) Notations dedicated to real-time
AADL in its definition aims to develop the software and hardware architecture of critical or distributed real-time systems. It therefore allows the specification of properties for each type of component. The standard provides a set of predefined properties dealing with temporal aspects, concurrency, distribution (diagram showing the behaviour of threads based on automata), integrity, security and performance. For example, the language defines properties such as: Dispatch_protocol which allows you to specify the mode of operation of the component (periodic or not), Compute_Execution_Time, Deadline, etc. Each designer can also define its own properties. In addition, unlike version 1 of the language where semantic relating to time for the execution of threads, communication or mode changes are globally defined in a synchronous manner and therefore expressed with a single reference time (e.g. a single global clock), AADLv2 allows to define different time references (several clocks) in the case of a globally asynchronous system. The property “Reference_Time” allows you to specify different clocks for processors, peripherals, buses and memories.
5) Dependability
AADL makes it possible to formally define non-functional properties on models developed, which makes it possible to analysis tools to perform analysis of real-time scheduling, of performance, etc. Tools exist for the simulation of AADL models, for formal verification of system properties. AADL provides communication between components, giving the possibility to define the durations and analyse the rate of sending and receiving of messages in a model.
6) Example of illustration [
Each of these symbols has an equivalent textual notation, which we present in the following, with the example of the speed control system below.
The context diagram of this example is given by
In this diagram, one represents the speed control system and the various external entities with which the system communicates. The connection points are groups of ports, represented on the scheme by a half circle associated with a point. They are used to represent a set of ports, which can be either data ports (input and/or output) or event ports (input and/or output).
For example, the graphical representation of the component Brake Pedal and the corresponding output data port is given by the following
The small triangle represents the data port, which is actually the component interface with the outside world. The textual AADL model for this graph is given by the following code:
In this example, we declare a brake pedal device that has an output data port. The variable name of this port is brake_status, and the data type is Boolean. We also precise, with the reserved word flows, that this device is part of a flow specification, that it is a source of flow (flow source), that the variable for flow analysis is brake_status, and that the name of flow is Flow1. In order to perform the analysis of the latency through a flow, the property defining the latency time must be added to the flow attribute (for example, 10 ms). For a device (component), this value represents the latency between when the pedal is pressed and when the associated signal is available on the output port.
The block diagram of the problem of the speed controller can thus be represented in AADL as shown in
The corresponding textual declaration is given below:
We can now represent an implementation model based on: the declaration of the different types, how connections are made for a specific implementation and how the implementation of the flows can be specified to illustrate a complete flow analysis.
In AADL, a flow specification provides a flow visible from outside through the ports of a component, parameters or groups of ports. The declaration of an implementation of flow in a component implementation model shows how the flows are made: as a sequence of flow through sub-systems (sub-components) along connections from the flow specification of the input port to the flow specification of the output port.
The diagram (
In this picture, we have the implementation of a system (my_system.impl) constituted of two processes P1 and P2 that contribute to implement the specifications of flow F1. The direction (path) of flow F1 is specified in
the implementation section of the model in the following way F1: port_1- > C1- > p1.F5- > C2- > p2.F7- > C3- > port_3.
The AADL model of the speed control system with the connections between components is shown in
7) Strengths and weaknesses
AADL is a language for architectural modelling. The strength of this standard is that it can cover both most of the different layers of the system (hardware aspects, networks, systems, Middleware and applications), and most of the stages of the development cycle (specification, analysis, integration). It offers a strong semantic particularly suited to the description of real-time critical embedded systems. The second version of AADL standard provides abstraction concepts for the implementation of a model-driven approach, which ensures maintainability and facilitates the analysis of the systems developed, meeting the current challenges of industrial computing. The MDA approach and strong semantics also facilitate the development of tools of analysis and transformation of the model representing the system, paving the way towards a better integration of formal verification techniques. A characteristic of the power of AADL is its ability to model the hardware of the target system. The binding of software components to hardware components allows the designer to specify and evaluate the effects of interactions of the complete system. In addition, AADL provides features for textual, graphical and XML representations.
One of the main weaknesses of AADL is that it does not provide elements to model clocks in the design of a system.
1) Presentation
SysML [
2) Usability
SysML replaces UML classes by blocks for a vocabulary more suitable to Systems Engineering. A block encompasses any concept of software, hardware, data, process, and even of human resources management. SysML reuses a part of UML2, and also provides its own definitions. Therefore, it does not use the thirteen diagrams of UML2, but provides a set of diagrams suitable for Systems Engineering. SysML supports the exchange of data
and models via XMI (XML Metadata Interchange).
For modelling a system, SysML provides a set of diagrams divided into 3 categories relative to the views of systems:
-Structural diagrams that describe the components of the product and its environment. Among these we have in particular the parametric diagram, which is a SysML extension for analysis of critical parameters of systems;
-Dynamic diagrams that model the behaviour of the system in response to its environment;
-The requirements diagram, which is a SysML extension.
The order of presentation of these diagrams does not define the methodology for modelling a system with SysML.
The SysML language is incorporated in some commercial software like Sparx Systems Enterprise Architect (SysML plugin), IBM Rational Software Modeler, MagicDraw (SysML plugin required) and open source software as TopCased (Eclipse), Papyrus, and OpenEmbeDD TTools. In the latest, the tool which analyses the SysML models combines simulation and formal verification, and it answers the need to detect design errors in the earlier phase of the system life cycle.
3) Compositionality
SysML provides diagrams for modelling various components of a system by a hierarchical decomposition approach. Thus, the block diagram is used to represent the system in different blocks composing it. The internal structure of each block can then be detailed, so as to present the sub-components which make up the block. This operation gives the hierarchical system architecture.
4) Notations dedicated to real-time
The subset of UML diagrams retained by SysML includes sequence diagrams and state transition diagrams, which allow to define temporal aspects of a system. In addition, the SysML’s parametric diagram that defines the parametric model of a system (various system parameters, with the rules and equations making it possible to have them), may contain temporal equations of the system.
5) Dependability
AVATAR language [
6) Example of illustration
One of the specificities of SysML compared to UML being its requirements diagram, we will focus on that aspect. In the requirements diagram, one specifies, prioritize and document requirements, i.e. the expectations relating to the system or to its behaviour. So, in this diagram, one will put a text which specifies all sorts of encrypted features, technological choices imposed, the compliance with the standards, etc.
A definition of the requirements of the speed control system is given in
In this diagram, we define two requirements REQ_CCS_01 and REQ_CCS_04, and we precise that the speed control system must satisfy those requirements (the “satisfy” dependency). The dependency “refine” of UML is used to indicate that an element of a SysML model is a refinement (more accurate) of a textual requirement. The dependency “verify” as for it shows the link between a test case and the requirements it must satisfy.
The speed control system which is a component of a more complex system (the vehicle), can be divided into its various components showing the properties of each subsystem, each with its input/output ports.
7) Strengths and weaknesses
SysML offers the advantage of being accessible to software developers that will find many similarities with
UML2. SysML can produce specifications in a single language for heterogeneous teams, responsible for the implementation of hardware and software blocks. Knowledge is thus modelled in a single repository that improves communication among the participating teams, is open to all and allows the reuse of the blocks built. A peculiarity of SysML is to regroup the three views of a system (structural, functional and behavioural) in a single multi- viewpoints model. The use of a single model has two significant advantages:
-This ensures consistency of data as SysML rules give each model element a single definition, built by gathering information from its different representations, and forbid them to contradict. This also reduces the risk of errors;
-It facilitates the use of simulation as a SysML model can assemble all the information needed to model the system, to simulate its behaviour and to compare the results with the requirements in order to validate (or not) solutions.
SysML has weaknesses:
The genericity of some concepts, such as block is a source of misunderstanding and needs to be quickly clarified when modelling. SysML can be seen as a high-level language for the analysis and design of complex systems to some granularity, but that is not sufficient for the complete development of a system. Indeed, at a certain stage of modelling, we are faced with diagrams on which hardware and software were identified, and which must be completely specified, but SysML does not make it possible.
1) Presentation
MARTE [
2) Usability
MARTE provides support for the stages of specification, design and verification/validation. It provides graphical representations and textual notations. This semi formal language is intended to be sufficiently accurate to be exploited automatically by software for analysis, code generation, testing or documentation. Thereby it fits completely in a model driven engineering process. MARTE is structured around two main concerns:
-Firstly, the modelling of the characteristics of real-time and embedded systems;
-Secondly, the annotation of application models to analyse the properties of the system model.
It is composed of 14 sub profiles grouped into 4 packages, each dealing with one aspect of the system:
-The package MARTE foundations which includes the general concepts necessary to the above-mentioned concerns. It includes, as sub profiles, CoreElement, NFP, GRM and Alloc profiles;
-The package MARTE design model bringing together sub-profiles dedicated to the design, namely GCM, HLAM and DRM;
-The package MARTE analysis model combining the sub-profiles dedicated to the analysis which are GQAM, SAM and PAM;
-The package MARTE Annexes gathering the utilities or transverse sub-profiles and template library.
MARTE is a relatively young standard, and therefore the number of tools supporting it remains low, but is intended to increase rapidly in the coming years. There are UML modelers that currently support profile MARTE:
-Papyrus: it is free and is part of the Eclipse project. It provides the reference implementation of MARTE;
-RSA (Rational Software Architect): it is marketed by IBM. It supports MARTE through one profile provided under a free Eclipse license by Thales Research Technology;
-MagicDraw marketed by NoMagic;
-OpenEmbeDD: it is a generic platform based on Model Driven Engineering (MDE) technologies, and integrating tools for help in the design of embedded real-time applications. The MDE technologies used in OpenEmbeDD are based on the Eclipse environment.
3) Compositionality
The design of the whole system is modular. Based on his needs, the user can select a particular subset of the 14 sub-profiles of MARTE. MARTE has a component model that makes it possible to define the various components of a system, their interactions (connection between components) and to specify the types and elements they exchange. This allows to define an (hierarchical) architecture of the system.
4) Notations dedicated to real-time
The sub-profile NFP (Non Functional Properties) and its specialization Time are one of the major contribu- tions of MARTE. They allow the description of non-functional system properties (qualitative or quantitative) with in particular a refinement for the annotation of temporal properties of real-time systems. The sub-profile HLAM (High Level Application Modelling) provides concepts for modelling both quantitative (period, time) and qualitative (behaviour, communication, concurrency) characteristics of real-time systems. The central concept proposed here is that of real-time unit (RtUnit) that encapsulates an autonomous processing resource and is the central concept for concurrency management. In the development of real-time systems, it is crucial to be able to analyze the possibilities of real-time scheduling of these systems. Thus, the SAM package (Scheduling Analysis Model) provides annotations dedicated to this schedulability analysis. The package PAM (Performance Analysis Model) is particularly dedicated to the analysis of temporal performance of soft real-time systems.
5) Dependability
Models produced with MARTE are usually annotated. Indeed MARTE makes it possible to define non- functional properties (NFP: Non Functional Properties) of systems, thus making the models a bit more formal. These NFP provide to the models the information necessary to perform specific analysis. So, a MARTE model will be able to support performance and scheduling analysis. But MARTE also defines a general Framework for quantitative analysis which aims to refine/specialise any other kind of analysis. Moreover MARTE offers packages for the annotation (SAM) and analysis (WFP) of models.
6) Example of illustration
As UML profile, MARTE is based on the concept of stereotype, to represent the different elements of a model.
In
FlowSpecification is part of the sub profile GCM (Generic Component Model) of the package “MARTE design model”. It is the sub profile which makes it possible to model system’s architecture as well as exchanges between its components. So it is relevant here.
Note in
These interfaces can therefore be used in the system’s architecture model to define the input and output elements of the different ports.
The speed control system, in turn, can be decomposed, which gives us the model of
7) Strengths and weaknesses
The increasing of complexity of real-time embedded systems has necessitated an increase in the level of abstraction of the languages intended for their modelling. MARTE is the first example of language making it possible to model most aspects of these systems with great consistency.
MARTE is a UML profile, and as such benefits from the advantages offered by UML profiles.
In addition to benefits common to UML profiles, MARTE has specific advantages. Among others:
-It provides a common way to model the software and hardware aspects of an Embedded Real Time System to improve communication between developers;
-It enables interoperability between development tools used for the specification, design, verification and code generation.
However, MARTE has some limitations.
MARTE is constrained by the UML meta-model. In MARTE, the concept of time is very ambiguous [
In this sub-section, we present comparative tables making it possible to classify approaches according to criteria defined in Section 2. This tabular presentation provides a major advantage for users in the domain, for the choice of an approach for their needs. Indeed, the analysis of each table shows which approach is the right one for a particular purpose, according to the score in the criteria which are important for the user. In the same logic, for each table, we provide a graph (2D histogram) for more clarity. We present six tables with scores of approaches on: 1) Usability 2) compositionality, 3) the real-time aspects, 4) dependability, 5) codesign and 6) the whole of the 5 criteria. Each table provides scores to the elements taken into account in the criteria, followed by a chart that provides an overview of each approach with respect to the criterion considered. The numbers displayed on the graphs (Figures 36-40) are obtained by summing the scores of items that are considered in the evaluation of a given criterion, and which are detailed in the table preceding the graph. An empty row in the table divides the methods (above the line) and the languages (under the line).
Tables 1-5 were constructed by assuming that the elements that enter into the evaluation of a criterion (e.g. for Usability criterion: ease of use, clarity of diagrams, notations available, availability of tools) have the same weight. Similarly, for the overall scores given in
the application, one can assign different weights to the criteria in order to take into account the relative importance of each criterion.
This paper presents different approaches for analyzing and designing real-time and embedded systems, in order to guide the designers of these systems, for the choice of approach to use, according to their needs and aspects to model. A survey of the current methods and languages is done from which was proposed a set of objective elements for their evaluation. For each approach, the features offered for the following aspects have been presented: usability, associated tools, compositionality, real time, dependability. Comparative tables and graphs have been proposed showing the relative position of each approach with respect to the others. The approaches were first compared on four criteria separately (usability, compositionality, real time and dependability), before being evaluated on the basis of a combination of criteria. The combination has been done with the assignment of identical weights to different criteria. However, the adoption of different weights is possible to take into account the relative importance of each criterion.
In this work are also presented the notations and concepts offered by the approaches to model a system and illustrated their use through an example, in order to enable readers to assess the degree of coverage of each criterion for each approach and to understand the score given for each criterion. This work shows that in general, methods and languages do not cover all the phases (and aspects) of the development of embedded and real time systems. This is reflected in the comparison tables, by the variation of marks obtained by each approach according to the criterion. Special mention is made, to languages such as UML, SysML, UML-MARTE and AADL, which offer notations and diagrams for most of the phases of the RTES development cycle, and also to the HOOD
Number | Approach | Easy handling, ease of use | Clarity of diagrams | Representation and notations | Support for code generation | Tools | Usability ratings | ||||
---|---|---|---|---|---|---|---|---|---|---|---|
graphic | textual | XML | free | owner | |||||||
Methods | 1 | CORE | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 4 |
2 | JSD | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 5 | |
3 | YSM | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 5 | |
4 | RTSAD | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 6 | |
5 | DARTS | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 4 | |
6 | ADARTS | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 4 | |
7 | CoDarts | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 4 | |
8 | MASCOT | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 4 | |
9 | HOOD/ HRT-HOOD | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 6 | |
10 | ROOM | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 5 | |
Languages | 11 | UML | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 7 |
12 | UML-RT | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 5 | |
13 | SysML | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 8 | |
14 | AADL | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 8 | |
15 | UML-MARTE | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 7 |
Number | Approach | System design | Components specification (component model) | Hierarchical architecture (hierarchical decomposition) | Compositionality ratings | |
---|---|---|---|---|---|---|
Methods | 1 | CORE | 0 | 0 | 1 | 1 |
2 | JSD | 0 | 0 | 1 | 1 | |
3 | YSM | 0 | 0 | 1 | 1 | |
4 | RTSAD | 0 | 0 | 1 | 1 | |
5 | DARTS | 0 | 1 | 1 | 2 | |
6 | ADARTS | 0 | 1 | 1 | 2 | |
7 | CoDarts | 0 | 1 | 1 | 2 | |
8 | MASCOT | 0 | 0 | 1 | 1 | |
9 | HOOD/HRT-HOOD | 0 | 0 | 1 | 1 | |
10 | ROOM | 0 | 0 | 1 | 1 | |
Languages | 11 | UML | 0 | 1 | 1 | 2 |
12 | UML-RT | 0 | 1 | 1 | 2 | |
13 | SysML | 1 | 1 | 1 | 3 | |
14 | AADL | 1 | 1 | 1 | 3 | |
15 | UML-MARTE | 0 | 1 | 1 | 2 |
Number | Approach | Communication | Synchronization mechanisms | Time management | Real-time ratings | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Priority on message | By message | data exchange (shared data) | Event Management | signals Management | mutual exclusion/ semaphore | monitor | Appointment | Time measure | Clock management | Multiple clock management | ||||
Methods | 1 | CORE | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 3 |
2 | JSD | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 4 | |
3 | YSM | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 5 | |
4 | RTSAD | 0 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 5 | |
5 | DARTS | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 7 | |
6 | ADARTS | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 7 | |
7 | CoDarts | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 7 | |
8 | MASCOT | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 7 | |
9 | HOOD/ HRT-HOOD | 0 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 5 | |
10 | ROOM | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 5 | ||
Languages | 11 | UML | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 4 |
12 | UML-RT | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 5 | |
13 | SysML | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 3 | |
14 | AADL | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 8 | |
15 | UML-MARTE | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 10 |
Number | Approach | System insurance | Service quality management | Model analysis | Dependability ratings | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Formals notations | Formal verification | Error modeling | failure analysis (delays, sending or reception rate) | Communication safety (in terms of message loss) | Interactions security between components | Schedulability analysis | Performance analysis | Models simulation | ||||
Methods | 1 | CORE | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 3 |
2 | JSD | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | |
3 | YSM | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
4 | RTSAD | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
5 | DARTS | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
6 | ADARTS | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
7 | CoDarts | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
8 | MASCOT | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
9 | HOOD/ HRT-HOOD | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 4 | |
10 | ROOM | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 2 | |
Languages | 11 | UML | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 |
12 | UML-RT | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2 | |
13 | SysML | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 4 | |
14 | AADL | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 9 | |
15 | UML-MARTE | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 8 |
Number | Approache | Code sign | |
---|---|---|---|
Methods | 1 | CORE | 0 |
2 | JSD | 0 | |
3 | YSM | 1 | |
4 | RTSAD | 0 | |
5 | DARTS | 0 | |
6 | ADARTS | 0 | |
7 | CoDarts | 0 | |
8 | MASCOT | 0 | |
9 | HOOD/HRT-HOOD | 1 | |
10 | ROOM | 0 | |
Languages | 11 | UML | 0 |
12 | UML-RT | 0 | |
13 | SysML | 0 | |
14 | AADL | 1 | |
15 | UML-MARTE | 1 |
Number | Approache | Usability | Compositionality | Real-time aspects | Dependability | Codesign | Global ratings | |
---|---|---|---|---|---|---|---|---|
Methods | 1 | CORE | 4 | 1 | 3 | 3 | 0 | 11 |
2 | JSD | 5 | 1 | 4 | 1 | 0 | 11 | |
3 | YSM | 5 | 1 | 5 | 0 | 1 | 12 | |
4 | RTSAD | 6 | 1 | 5 | 0 | 0 | 12 | |
5 | DARTS | 4 | 2 | 7 | 0 | 0 | 13 | |
6 | ADARTS | 4 | 2 | 7 | 0 | 0 | 13 | |
7 | CoDarts | 4 | 2 | 7 | 0 | 0 | 13 | |
8 | MASCOT | 4 | 1 | 7 | 0 | 0 | 12 | |
9 | HOOD/ HRT-HOOD | 6 | 1 | 5 | 4 | 1 | 17 | |
10 | ROOM | 5 | 1 | 5 | 2 | 0 | 13 | |
Languages | 11 | UML | 7 | 2 | 4 | 2 | 0 | 15 |
12 | UML-RT | 5 | 2 | 5 | 2 | 0 | 14 | |
13 | SysML | 8 | 3 | 3 | 4 | 0 | 18 | |
14 | AADL | 8 | 3 | 8 | 9 | 1 | 29 | |
15 | UML-MARTE | 7 | 2 | 10 | 8 | 1 | 28 |
method which, in addition to being object-oriented, defines a fairly standard development life cycle. One of the main perspectives of this work is therefore to take advantage of the features offered by these four languages in the development cycle, to combine them and to propose a process based on these languages and on existing methods such as HOOD, to cover effectively the whole RTES development cycle.
Valéry M. Monthe,Laurent Nana,Georges E. Kouamou,Claude Tangha, (2016) A Decision Support Framework for the Choice of Languages and Methods for the Design of Real Time Embedded Systems. Journal of Software Engineering and Applications,09,353-397. doi: 10.4236/jsea.2016.97025