Part C - Semantic Scholar

5 downloads 2628 Views 435KB Size Report
evaluation and comparison of the modeling approaches in section 3 . The reader is .... Unicon and Rapide support software architecture description. Lustre and ...
Part C

A Survey of Modeling Approaches for Embedded Computer Control Systems by Jad El-khoury, DeJiu Chen and Martin Törngren

Technical Report, TRITA-MMK 2003:36 ISSN 1400 –1179, ISRN KTH/MMK/R-03/11-SE, 2003. Submitted for Journal publication.

129

130

A Survey of Modeling Approaches for Embedded Computer Control Systems Jad El-Khoury, DeJiu Chen, Martin Törngren Mechatronics Lab, Machine Design, Royal Institute of Technology, S-100 44 Stockholm, Sweden E-mail: [email protected], [email protected], [email protected] Abstract Model-based system development emphasizes the usage of models throughout the development process. In such an approach, modeling becomes of central importance, forming a basis for documentation, communication, decision-making, and design automation. As this design paradigm becomes gradually adopted for the development of embedded computer control applications, new modeling requirements become apparent. This work presents a survey of current modeling approaches that attempt to meet some of these needs. A framework for characterizing, comprehending and comparing the different approaches is developed, focusing on the modeling content and features that are specific to model-based development. In addition, the associated representation techniques and tool support are studied. The framework is presented together with lessons learned. The framework combines generic concepts of systems with modeling concepts extracted from a study of twelve modeling approaches covering different levels of design and disciplines. This approach ensures that many aspects of the modeling and development process are covered, resulting in a framework that is quite reasonable and practical for comprehending and comparing the studied approaches. The survey helped discover common concepts and patterns, as well as unique ones, which will be the basis for further refinement of the framework. This refinement process will also be supported through the introduction of additional modeling approaches in the survey from the various domains of mechanical, control and computer engineering. This work is part of a larger effort to define a modeling approach suitable for complex embedded control systems.

131

132

1

Introduction Embedded computer control systems refer to digital computers that are used for achieving advanced control functionality as well as diagnostics and monitoring in machinery such as vehicles, airplanes, production machines, and robots. Because of the dynamics under control, embedded computer control systems differ from other general-purpose computer systems with respect to two important qualities: real-time performance and safety criticality. First, since either a too early or a too late completion of control functions can negatively affect the performance and stability of control and may result in system failure, embedded computer control systems are real-time systems. Second, since such computer systems, if not performed, performed incorrectly, inadvertently, or out-of-sequence, can result in a hazard or allow a hazardous condition to exist, they are often safety-critical as well. During the development of embedded computer control systems, modeling plays an important role. It defines a set of abstractions that are of particular concern and provides representations and rules for using these abstractions. The descriptions or models then form the basis for all other activities in the development, such as communication between stakeholders, analysis and design decisions documentation. To ensure success, the underlying system descriptions have to be consistent and traceable, as well as complete and analyzable. As embedded computer control systems become larger and more complex, describing various system aspects using different models and integrating these models in such a way that the abovementioned basic properties of modeling are satisfied becomes a challenging area. The multidisciplinarity of engineering and the complexity management issues that arise during the development of large systems place special requirements on the modeling approaches of embedded control systems. This article surveys some current approaches for modeling computer systems. The aim is to study ‘what’ each approach models, with less focus on the details of ‘how’ this is performed. For this purpose, a framework for characterizing and comparing various modeling techniques has been developed. Issues that are of particular concern in the framework include both the contents of models in terms of the predefined abstractions and their contexts-of-use in terms of quality analysis and other development activities. The framework can be used as a basis for reasoning about the adequacy of a modeling technique or for developing new modeling techniques or languages for model-based development of embedded computer control systems. The comparison framework is presented section 2 , followed by the results of the evaluation and comparison of the modeling approaches in section 3 . The reader is referred to the more detailed report in [1] for detailed summaries and comparisons of the studied approaches.

1.1. Approach One challenge in defining any comparison framework is to ensure that aspects covered in the survey are general enough so that they are not restricted to a particular modeling concept but still detailed enough to capture the characteristics of existing modeling approaches. To seek a balanced solution, we have studied both generic 133

concepts of systems and existing modeling approaches when defining the framework. The idea is illustrated in Figure 1. Based on the concepts of systems and system design, we developed a preliminary definition of the framework. The identified criteria represent theoretical features of embedded control systems, forming a hypothesis for what constitutes essential parts of a modeling approach. This is referred to as top-down synthesis. Then, a number of existing modeling approaches were used to evaluate and refine the framework.

!

"

#

Figure 1. Technique for defining the framework – Top-down synthesis and bottom-up refinement The choice of approaches for this survey is hence important for the definition of the comparison framework. By modeling approach we refer to any design support technique or solution that is provided for the designer of embedded computer control systems, such as computer tools, languages and standards. The initial selection criterion is to include approaches that are relevant to the development of embedded control applications. This can range from dedicated approaches that explicitly deal with such systems to more general approaches that support certain relevant system aspects or issues. While this criterion objectively rules out a wide selection of approaches, many approaches still justly qualify for comparison. However, time limitations constrain the amount that can be covered. For this reason, we have opted to sample one or two approaches from each style or category of approaches that support in some way the development of real-time control systems. A category can be the level at which an approach is used in the development process such as architectural or implementation-level design, or the research community from which it stems such as formal methods or industry, or the application domain targeted by the approach. We have aimed for a breadth, and not depth, coverage in order to identify a wide range of concepts to include in our framework. It is recognized that such sampling is in no way comprehensive, or even representative of all proposed approaches. However, having covered a range of different types of approaches, it is hoped that a broad collection of features, which might be included in other uncovered approaches, is captured during the refinement stage. 134

Such an approach would produce a fairly stable framework, but it is expected that some changes would occur when other approaches or concepts are taken into account in the future. For this reason, we have built in some flexibility (the other factors) into the current framework in order to capture any potential aspects that need to be handled as a separate factor in the future. The following approaches have been evaluated based on published materials from the respective developers: •

ACME is an architecture description language (ADL) and toolset, developed by Carnegie Mellon University since 1995. It is intended to be a common interchange format for other architecture design languages and tools. [7][8]



Giotto is a programming language for embedded hard real-time control systems with periodic behavior. It is developed at the University of California at Berkeley. Giotto separates the platform-independent functionality and timing concerns from platform-dependent scheduling and communication issues. [9][10][11]



Lustre is a formal approach that adopts the synchronous paradigm, providing a simple and verifiable way of designing the system functionality. Its data flow model is similar to conventional control design. [12][13][14][15][16][17][18]



MAST is developed by the computer and real-time group, at the University of Cantabria, Spain. It is a modeling approach whose foundation evolved from the need to perform timing analysis of a system. [19][20][21]



MetaH is a language and toolset for describing, analyzing, and implementing real-time safety/mission critical computer systems for avionics control applications. It is being developed by Honeywell Technology Center since the 1980s and is currently being extended into an Avionics Architecture Description Language (AADL). [22][23][24][25][26][27][28]



Orccad is jointly developed by the BIP project and the Robotics Department of INRIA Rhône-Alpes. It is a software environment dedicated to the design and implementation of advanced robotics control systems. It also allows the specification and validation of missions to be achieved by the system. [29][30][31][32][33]



Ptolemy is developed at the Department of Electrical Engineering and Computer Sciences of the University of California at Berkeley. Ptolemy facilitates functional description by providing various models of computations and hence allowing different domains to be described in the same language. [34][35][36][37][38][39]



Rapide is a language and toolset developed by Stanford University since 1996, with the aim of supporting component-based development of distributed, timesensitive systems. It utilizes an architecture concept for defining the abstractions and a formal basis for specifying and analyzing high-level behaviors and performances. [40][41][42]



SDL originated in 1972 and has since been developed by CCITT (International Telegraph and Telephone Consultative Committee). It has been designed to specify and describe the functional behavior of telecommunication systems, but has been used in various different applications. SDL focuses on a single descriptive mechanism for behavior, namely communicating Extended State 135

Machines, but can be used in combination with other languages such as MSC, ASN.1 and TTCN. [44][45][46][47] •

Unicon is a software ADL and toolset, developed by Carnegie Mellon University in 1995. The focus is on supporting the descriptions of architectural abstractions and styles found in various software systems and on constructing new systems from the architecture descriptions. [48][49]



VCC is a commercial tool developed by Cadence. It is a system-level development environment for platform-based hardware/software co-design for automotive systems. It allows architectural decisions like hardware to software partitioning at the early stages of design. [50][51]



Wright is a software ADL and toolset developed by Carnegie Mellon University in 1997. It supports the formalization of architectural styles, and model verification and validation based on a formal behavior description in CSP. [52][53]

Matlab/Simulink and the Unified Modeling Language (UML) are two approaches that are of wide interest and used in embedded control system, yet were not included in this study. We have chosen not to include Matlab/Simulink since this approach is well mirrored by other approaches that use the data-flow model of computation such as Ptolemy and Lustre; and it was preferred to study and investigate these less common approaches. Given that UML is currently evolving into a new version (UML 2.0), its study was postponed until a stable release is given. The objectoriented concepts of UML are covered by other approaches such as SDL, while the new software architecture aspects are covered in the studied ADLs such as ACME. It is expected that the application of this framework on these two approaches acts as a validation of our current study, which is planed as future work. An approach can well belong to more than one category or style. ACME, Wright, Unicon and Rapide support software architecture description. Lustre and MAST have a computer science origin with formal methods and scheduling theory background respectively, while VCC is an industrial approach. Orccad, Giotto and MetaH are domain-specific approaches that aim at control applications to be implemented on computer systems. Both Ptolemy and SDL focus on the high-level specification of the system, and less on implementation details. Another challenge facing our classification of a particular approach is the decision of what to be considered part of the approach and what is an external extension facility. For example, the MAST approach has the possibility to be integrated with a UML tool and hence extending its capabilities. Similarly, MetaH is accompanied with a sister language, ControlH, that allows the functional specification of its software modules. In this study, the sum of tools or languages that have been developed by the same team or in close cooperation are considered as an integral part of a single approach; while independent tools which have been integrated later during their development, are considered as extensions. Using this definition, the UML-extension of MAST and that of ControlH to MetaH are ignored when evaluating the approaches and are simply considered as powerful extensions. The survey compiled and presented is based on the authors'interpretation of published material from each of the projects. In many cases, it was not possible to obtain a single document that provided all the necessary information. The authors have hence resorted to a collection of publications. Many of these projects have been 136

developed over years resulting in publications that provided different, if not contradicting information. In such cases, we have attempted to remove all such ambiguities and used the latest publications as an authoritative reference only if the publication was authored by a member within the concerned project. Finally, feedback from representatives of some of these approaches has been taken into account.

1.2. Related Work Existing surveys of modeling approaches and modeling frameworks mainly differ in the type of approaches being targeted such as general-purpose software techniques, formal techniques, domain-specific techniques, etc. In addition, the coverage and levels of detail at which the survey is conducted varies. A third difference lies in the comparison framework devised to compare the concerned techniques, highlighting the aspects that the surveyors are interested in analyzing. A collection of surveys is presented in this section, illustrating the differences presented above. The survey in [2] targets models and tools for the design of embedded computer control systems. The survey studies solutions representing efforts from different communities and methods such as object-orientation, structured analysis, and scheduling analysis research. The established comparison criteria qualitatively identify the extent to which each solution handles specific issues such as timing behavior, structure and resource management. The authors also emphasize the importance of multidisciplinary, concurrent development, and multiple viewpoints in any given approach. This survey only tackles a small subset of issues relevant to modeling. Each issue is also considered in coarse and broad terms, which may make it hard to compare different approaches, since each approach may cover a different subset of the same issue. The modeling survey in [3] studies and describes a range of modeling techniques that may be relevant to the development of robotic systems. The techniques considered are mainly basic modeling formalisms, such as differential equations and Petri-nets, together with a couple of languages and tools that integrate some of these formalisms. A classification scheme is suggested investigating properties such as whether the modeling techniques are deterministic or stochastic in producing output results relative to the input, incorporate the timing aspects of the system, assume a discrete or continuous model of the system, as well as whether analysis can be performed on the models. However, this scheme is not directly applied to the chosen techniques in the survey. The survey in [4] covers a wide range of software specification approaches from the structured and object-oriented communities. Here, a modeling method, such as Statemate, Shlaer&Mellor, and UML, is considered to consist of a set of basic specification techniques, such as natural languages and diagrams, together with interpretation and interconnection rules to combine them into a coherent specification. The comparison framework is performed on those basic techniques. In establishing the framework, a system is viewed as an aggregation hierarchy of parts, and a technique is used to specify the system, as well as its parts’ properties of functions, communications, and behavior. The comparison framework is hence specified using these three properties on both the system and its parts, plus the actual decomposition property of the system to its parts. The framework is later analyzed to

137

establish similarities and differences in the way methods use these techniques, and helps pointing out opportunities to combine them. While covering a wide range of methods, the survey focuses only on general software. In [5], a survey of software Architecture Description Languages (ADLs) is performed. In their work, the authors attempt to use a comparison framework to resolve the issue of whether a particular language classifies as ADL. The established framework classifies each approach mainly based on the three categories of architectural-level abstractions: components, connectors, configuration, plus tool support. These high-level abstractions are further broken down into other features from functional features such as interface and behavior, to non-functional features such as usability and scalability. When used to classify languages, certain categories and features are specified as necessary in order to rule out or include a certain language as an ADL, setting the minimum requirements for ADLs. By nature of ADLs, this survey only focuses on approaches that are used in early design stages of the system. In [6], a classification and comparison framework for software ADLs is defined by studying other ADL surveys and specification languages. Compared to the abovementioned survey, the framework focuses on a set of user-visible features necessary to define an ADL (referred to as feature analysis), and less on the characterization of technical issues. The criteria are organized in three major groups: system-oriented features, language-oriented features, and process-oriented features. In general, these comparison frameworks often focus on modeling itself and do not pay enough attention on the context issues. The lack of perspective - the explicit considerations on the relations of modeling with quality analysis and other development activities - limits the usefulness of their conclusions for the purposes of this study.

2

Comparison Framework

2.1. Model-based Design and Analysis The comparison framework is defined with a model-based approach to system development in consideration. Such an approach differs from other approaches by emphasizing the usage of models for the purposes of design and analysis throughout the whole development process. In such an approach, modeling provides a means of documenting the system under development, while analysis of system qualities provides a means of verifying the system solutions before the actual components or systems have been built. The design space and accuracy of analysis results are constrained by the available system information in the models and the analysis methods. Hence, the context in which a modeling approach is intended to support becomes a central issue in defining a characterization and comparison framework of modeling approaches. The idea is illustrated in Figure 2.

138

) (

$% '%

& &

(

(

Figure 2. The design-modeling-analysis relationship in model-based development. Modeling refers to the techniques of abstracting and describing important system features, and provides supports for using and validating them. An important goal of modeling is to describe and document the properties of a system so that it can be comprehended, communicated, documented, analyzed, or modified correctly as design proceeds. The various system aspects, their properties and the different relationships existing between them, which are represented in a model, are here referred to as modeling content. System design refers to the activities of making solution-oriented decisions that satisfy given requirements and constraints for the intended product. Analysis verifies how well the resulting system satisfies these given requirements. From a system development perspective, analysis provides means for guiding design decisions and verifying the system solutions before the actual components or systems can be built. In model-based analysis and design, the design activities and the product qualities that are of interest to analysis will impose requirements on the modeling content, the information management and representation techniques adopted. In terms of modeling content, two fundamental criteria for any modeling approach are that of completeness and consistency. Completeness relates to the sufficiency and meaningfulness of information provided by models. This is a relative concept that depends on the intended usage of models as well as the levels of design. In a modelbased development, a complete system description enables critical properties to be evaluated before the system is built. For computer control systems, one notion of completeness is that a specification of system behavior should cover both normal and abnormal behaviors in terms of failure modes (omissions and value errors) [54][55]. Consistency relates to the agreements of information provided by different parts of a model or different models. This issue arises when a description is refined or transformed into others (e.g., different models for different purposes), or when the same properties are described in two parts of a description. (See [56] [57]) From the designer perspective, factors such as complexity management and traceability of information also become important as the system under development gets larger. Traceability relates to the management of information changes during the system development timeline. It is important for development of complex systems, which can be considered as a complex causal network where every action has implications on other actions [58]. As mentioned in [59], many serious accidents and losses are due to the fact that design decisions or changes were not fully analyzed to 139

determine their effects. Complexity reduction relates to the ways of structuring and representing information, making it easier for the users to absorb it. Among others, hierarchy provides a means of layering information so that different concerns can be comprehended separately. Views can be used to organize system representations for particular disciplines, design stages, or stakeholders [60][61][62]. In addition to these general requirements, the nature of embedded computer control systems present specific modeling needs. One special feature of embedded computer control systems is the need to support the interactions of multiple engineering domains involved in the system design, such as mechanical engineering, automatic control, computer software and hardware. Information from each of these engineering domains depends on and constrains each other. For example, the design of automatic control forms part of the functional requirements on the computer systems. Another important requirement is to provide information about the underlying implementation technologies. The choices of hardware technologies and allocations often affect the feasibility and qualities of an application. The target environments are often characterized by restricted resources, increasing the need to take them into consideration during design. Moreover, it is necessary to deal with the environment in which a computer system exists and operates, such as states and actions of physical processes and physical conditions in terms of temperature, electro-magnetic interference, road condition and speed limits. During different development stages of a system, the issues and details that are of interest in regard to the environment may differ. Concerning analysis, besides supporting analysis of functionality, there is a need for models that provide sufficient information for the analysis of critical qualities such as real-time performance and safety. It can here be concluded that it is generally unreasonable to compare different modeling techniques without explicitly considering their design and analysis context. Therefore, to compare different modeling approaches and reason about how they can be integrated in system development, both the model contents and their usage context need to be considered. In the comparison framework, this is formulated using two groups of comparison factors: modeling content factors and modeling context factors. The former handles the various system aspects that can be modeled in the approach, together with their properties and relationships, highlighting the above-mentioned embedded computer control features. The latter represents a set of basic characteristics of system design and analysis that are supported. Two other userrelated groups of factors, representation and tool support, are also handled in the framework, dealing with issues such as representation techniques, and support for manipulating, managing and verifying the models. These factors are summarized in Figure 3 and explained in the following sections.

2.2. Content The content factors of the framework aim to identify what issues of a system a particular modeling approach tries to model. In order to be able to compare the different modeling approaches in a fair and balanced way, a common basis is necessary leading to the need to derive a generic model-of-models. In this framework, a model is seen as consisting of a set of abstractions that represent the real system entities. We differentiate between real entities and modeling abstractions, since abstractions only reflect certain aspects of the entity it represents,

140

which are considered relevant for the given approach. (In the same way a model is only a representation of the real system and does not ever deal with all of its details.) The abstractions in a system may be classified into a set of common types. Design Context Levels Activities Domains & Disciplines Methodology Traceability Complexity Management Reusability

Analysis Context Functionality Performance Reliability Safety Other

Language Representation technique Adaptability Multi-views Consistency guarantee

Tool

Content Abstractions Properties Structural interface Behaviour Semantics Activation Persistence Timing Error Constraints Inter-abstraction Relations Decomposition Encapsulation Behaviour Semantics Constraints Communication Behaviour Semantics Constraints Synchronisation Behaviour Semantics Constraints Commonality Dependency Refinement Allocation Criticality Replication Other

Availability User interaction Tool integration System Generation

Figure 3. The comparison framework’s main categories of factors Within each type, instances differ by adapting different properties. Furthermore, there exist different types of relationships between the different abstractions, which integrate and relate the abstractions to each other, such as communication between abstractions and decomposition of one abstraction into a set of other types of abstractions. Following this view on models, the set of abstraction types, the properties that define them, and the relationship types that may exist in any modeling approach are identified, and form the common basis upon which it is possible to classify the content support provided by each modeling approach. In the same way a model can never model a system completely, there can never be a complete set of such types of abstractions and their relationships. The content factors in this framework are hence defined to cover all the recognized features. In future developments, it may be necessary to further break down certain factors in order to highlight more specific issues. In addition, there seems to be a subtle difference between the concepts of abstractions, properties and relationships. Isn’t every ‘thing’ in the system an entity and hence considered an abstraction in the model? This is a very valid argument, but unfortunately does not lead to a very useful comparison framework, and a certain 141

informal definition of the difference between these three concepts needs to be presented. In defining this framework, the decision of whether something is a property or an abstraction is based on subjective judgments. Given that these judgments are carried out consistently, a fair comparison between the approaches can be guaranteed. In addition, as long as the comparison between the approaches is based on the same framework, it is of less criticality whether a certain aspect is considered an abstraction or a property. As a general guideline, if some ‘thing’ can be directly classified as a property or a relation in the framework, then it is not necessary to, and will not, be classified as an abstraction. For example, in Ptolemy the director is not treated as an abstraction, since it more suitably represents behavioral properties of the actor abstraction. Adopting the approach discussed in section 1.1 helps in dealing with the above issues. An initial analysis defines a set of abstractions, their properties and relationships that are then further refined once the survey was performed in order to find a more balanced framework. This also helps resolving one common problem when studying and comparing modeling approaches - the interpretations of approaches and their terminologies. For example, due to their different backgrounds, the same term can represent different things of system. The terms ‘process’ and ‘task’ as used by MetaH and MAST respectively are essentially equivalent, while they may have a different interpretation in the general software community. In a sense, this content classification follows a generic concept of systems – a synergetic integration of different things for certain purposes (i.e., constituents, relations, and attributes) [60][63][64]. In summary, we identify and organize the fundamental modeling content features into two major groups of modeling factors: abstractions, together with their properties and inter-abstraction relations.

2.2.1. Abstractions The abstraction factor in the framework classifies the abstractions covered by each modeling approach and provides a simple definition of each abstraction. Abstractions are categorized into a predefined set of categories, for better management and understandability of the content. The following categories have been identified as relevant for embedded control systems: •

Function abstractions represent high-level specification aspects of a system’s functionality or logic, independent of any implementation technology.



Software abstractions represent system solutions implemented as logic executing under a discrete processing unit such as processes, and their communication mechanisms.



Platform abstractions represent hardware units such as devices, processors and networks, as well as middleware solutions such as operating systems, services, compilers, etc.



Data abstractions represent information units (signals, tokens, events) that are present in the system. Data does not necessarily only deal with data variables at the implementation level, but can also include the information that flows between functions.



Communication abstractions represent the mechanisms, as well as physical medium, for the exchange of information between other abstractions.

142



System abstractions represent the complete system, together with its configuration properties.



Generic abstractions are those that can be considered as any of the other types of abstractions once specialised or depending on their usage context.

It may be the case that abstractions are encountered which do not fit best under any of these categories, so the other factor is included in the framework for any such unconsidered, or less notable, abstractions. Depending on the usage of the approach, abstractions can be categorized in different ways. For example, a process agent in SDL or a node in Lustre, can be either used to describe a system functionality, which is to be further refined into implementation depended solution, or directly describe the software of the system. The categorization should be viewed as informal and not exclusive, in the sense that an abstraction may very well belong to more than one category. For example, data abstractions for the communication of software can be classified under the data, communication, or software category. There is a certain hierarchy within the above categories. One can view the data and communication categories as subsets of each of the software and platform categories, with another data category under that of communication. Figure 4 illustrates a possible organisation of the abstraction categories. However, we choose to flatten the hierarchy to simplify our criteria structure and in order to avoid repetition, an abstraction is specified only once under the most appropriate category.

Figure 4. Possible hierarchy of abstraction categories. 2.2.1.1 Properties Abstraction properties are divided into two major types: structural interface and behavior semantics. The former property deals with an abstraction’s organization (what an abstraction is) relating to issues such as size, form and input/outputs. Such properties relate to an abstraction’s interaction interface with other abstractions. The interaction itself is dealt with under communication and synchronization (Section 2.2.2). The latter property deals with its behavior (what an abstraction does and how it generally does it) relating to issues such as response to stimuli, functional transformation, logic and storage. When dealing with these properties, we treat the abstraction as a black-box and only look at the properties as seen from the outside. These properties do not necessarily need to be defined externally. (See decomposition factor, section 2.2.2) It is still however valid to deal with such properties, as reflected on the external interface. More specific behavioral properties are highlighted by four sub-factors of behavior semantics:

143



Activation – refers to the conditions (data-driven, event-driven, time-driven, etc.) and mechanisms (triggering, autonomy, etc.) of initiation and execution during an abstraction’s lifetime.



Persistence – refers to the conditions and mechanisms for creation and destruction of an abstraction. This property is mainly concerned with the dynamism of abstractions.



Timing – refers to the timing aspects of an abstraction such as execution time, delays, jitters, deadlines, operation times, frequencies, etc.



Error – refers to non-desired behaviors of an abstraction. Any language that supports a general behavior description can use this same technique to describe error behavior. However, unless an approach provides explicit constructs for error description, the error behavioral properties are not considered as defined.

A third kind of abstraction property is constraints, which applies to both structural and behavioral properties. This property refers to the explicit definitions of boundary values, the allowed/disallowed set of values a certain property can take, without specifying exactly which value the property will actually take. A difference should be noted between the mechanisms available to the user to define restrictions on the system definition, and the modeling language rules and restrictions on how a system is represented (its syntactical rules). The constraints factor only deals with the former.

2.2.2. Inter-abstraction Relations Nine types of relationships between abstractions have been identified: •



Decomposition – refers to the allowed ways of composing abstractions forming a whole. That is, the predefined part-whole relationships between an abstraction and its contained abstractions. Note that abstractions at the interface of an abstraction can be considered part of the composition relationship, but since they have been dealt with in the structural interface factor (see section 2.2.1.1), they are not handled in this factor. There are three sub-factors introduced to highlight the interesting features of decomposition: Encapsulation – refers to the provided ways of externally accessing the (internal) parts of a whole that are not otherwise accessible through the abstraction’s interface. This factor does not apply for system-level abstractions since there are no external abstractions for a system to deal with. This mechanism strongly relates to information-hiding and modularity concepts. Behavior semantics – refers the implications on behavior when composing parts into a whole, such as persistence control and behavior composition. Constraints – refers to the restrictions on the given ways of composing parts into a whole such as distribution and safety requirements. Communication – refers to the allowed ways of connecting different abstractions for the information exchange or physical interaction. Two sub-factors are used to highlight the interesting features of communication: Behavior semantics – refers to the protocols, rules and implementation issues for communication, such as arbitrations, flow-control, timing, and error. Constraints – refers to the restrictions applied to communicating abstractions.

144





Synchronization – refers to the ordering and timing relations between abstractions. The scheduling of software abstractions can be seen as a synchronization between the scheduled abstractions as well as an activation (section 2.2.1.1) of the abstractions by the scheduler. In this framework, the scheduling mechanisms are dealt with under synchronization. Two sub-factors are used to emphasize the interesting features of synchronization: Behavior semantics – refers to the behavior details such as precedence relations, scheduling, parallelism and errors. Synchronization between abstractions can be, and is most often, realised through communication (typically a synchronous communication protocol). However, this is not necessary as other indirect mechanisms may be utilised such as the use of offline scheduling to ensure synchrony between software tasks. Moreover, communication control can be simplified in the latter case. Constraints – refers to the restrictions applied to synchronizing abstractions. Commonality – refers to the common features’ between abstractions. Three types of commonality can be identified: (1) Typing where abstract types can be defined from which multiple instances are created, inheriting common properties. (2) Common configuration where patterns or styles are repeated across a collection of abstractions. (3) Specialisation/generalisation where an abstraction type is based on another abstraction type, together with some modifications, and hence sharing some properties that have not been modified. Pre-defined typing of abstractions such as periodic & aperiodic processes in MetaH is not considered in this factor. Such types are pre-defined in the languages as opposed to types that the user can specify, and are treated in the abstraction factor. A distinction needs also to be made between this factor, which deals with a relationship between abstractions in terms of sharing common properties, and reusability aspects (See section 2.3) that are useful techniques used during the design process such as the recycling of code segments in program functions.



Refinement – refers to the relationship between different abstractions of the same real-system entity from a less detailed abstraction to abstractions with more details towards the final result. This relationship is associated with the design process where implementation details are added successively. For example, a function refines another by adding implementation details that did not exist in the original. Another example is the partitioning of functions to tasks. Besides refinement during the design process, the decomposition (see above) of a whole into parts can be considered as a form of structural refinement where the composite abstraction is broken down into smaller parts that contain more details. However, such relationships are not treated in this factor to avoid repetition. Similarly, system generation (section 2.6) relates to the refinement of the system into the final product, and is not handled under this factor.



Allocation – refers to the mapping of software abstractions to platform/hardware abstractions. It is a kind of spatial relationship between abstractions and their physical hardware abstractions, such as functions to hardware or software to hardware. (The ‘allocation’ of functions to software is considered as a refinement relationship and not allocation.) In this framework, allocation differs from decomposition in that software abstractions are executed, but not contained, on the hardware abstractions. (A processor is fully defined whether software is allocated to it or not, hence the software is not part of the processor.)

145



Dependency – refers to the relationship between abstractions where one abstraction affects the other in terms of (1) a property of one depending on the properties of another, (2) or the existence of an abstraction depending on that of the other, (3) or assumptions taken by an abstraction concerning the other abstraction.



Replication – refers to abstractions that are identical replicas of each other. Explicit support for replication is required. It is not enough, for example, for an approach to support a typing mechanism whereby a type can be instantiated into two exact instances to be considered replication. An approach must explicitly handle replication mechanisms and rules, and deal with issues such as replicadeterminism, allocation, etc.



Criticality – refers to the relations between abstractions with respect to safety constraints.

Since it is not possible to rule out the existence of other types of relationships in a system, an other factor is included in the framework for any such unconsidered, or less notable, relationships.

2.3. Design Context System design is concerned with identifying the parts and functions of the system to be developed, organizing the structures and behaviors, and planning for the implementation. It handles issues such as actions to be performed, parts to be included, and how to configure these parts before the system is built. For this purpose, support from both modeling and analysis is necessary (section 2 ) Irrespective of the design process or methodology used during development, certain general steps are present. These steps include: requirement analysis and specification, design, implementation, unit test, system integration and integration test. During the earliest stage of system development, requirement analysis and specification is performed, describing the system’s intents and desired qualities, the external conditions and constraints (e.g., a context definition), technology constraints and preferences, and the stakeholders’ roles, etc. Since the issues are concerned with the problems to be solved, they represent the problem domain of a system. During the design stage, developers determine the system solutions for the given specification, including the required constituent entities, (such as functional subsystems, software programs, hardware and mechanical devices) as well as their properties and interrelationships (Section 2.2). To verify the conformance of the product with the specification, various tests are performed. The unit tests verify the constructed components or subsystems, while the integration tests verify the final system after integration. This survey focuses on the design step, which is further refined into functional design, architectural design, medium-level design, and detailed design: •

Functional design deals with the system solutions in functions or logic, independent of the underlying implementation means.



Architectural design provides the first implementation domain interpretation of the functional solutions and other requirements by defining the implementation

146

solutions in the large, such as what software and hardware units should be included, how they should behave, and what are their quality constraints. •

Medium-level design addresses the technology specific concerns of system implementation. It bridges the gap between the architectural-level design and the underlying implementation technology by resolving a set of implementation specific problems. At this stage, the design takes into account the characteristics of underlying system platform, such as available middleware services, topology, and hardware resources.



Detailed design focuses on placing the solutions into operations using a certain technology. For software based implementations, the detailed design in terms of programming and coding determines the structure of software programs (call structure, data structure, class structure, loading structure, etc.) and realizes the software using a certain programming language.

In the design context section of the comparison framework, the above-mentioned design levels that each approach focuses on are identified in the levels factor. An approach can be related to a wider range of levels, defining the boundaries of the intended design focus, which are highlighted in this factor. The activities factor refers to the various design activities that are performed at each design level. These activities can be classified based on the type of solutions that are under design – structural or behavioral solutions. Structural design activities deal with system structure, such as decomposition, partitioning, and allocation. Behavioral design activities deal with system behaviors, such as transformation, operations, ordering and synchronizing of functions and events, and scheduling of tasks. Other design activities concern the mapping of structural and behavioral solutions. Other design related factors are: •

Domains & Disciplines refers to the design support for engineering domains and disciplines that are relevant for embedded computer control systems such as mechanical, automatic control, software and electronics engineering. One important issue that needs to be addressed is the transformations of information across domains, which can be treated by providing explicit modeling support or by relying on tools that integrate external domain-specific models.



Methodology – refers to the support or adoption for a specific design methodology by an approach. This support may range from a mere mention of a preferred development process, to built-in assumptions that a certain methodology is followed enforcing the user to adhere to the suggested process.



Traceability – refers to the support for identifying and managing dependence of information over the design lifecycle. At any design stage, certain solutions may be incomplete, not optimal, or may be based on assumptions on details that are not yet available. As design progresses, changes are performed to reduce this incompleteness, optimize a solution or deal with previous assumptions. It is desirable to clearly document these changes in such a way that they can be checked and reconsidered in time as the design proceeds. Traceability is central for the efficiency of design by reducing unnecessary iterations and modifications. It permits (1) determining the correspondences between requirements and underlying implementations, (2) managing interdependence between different parts (functions, subsystems) of the system, especially hidden assumptions and expectations, (3) handling the change history of a system during its life cycle, and 147

(4) managing different solution variants/versions. This factor is closely related to refinement (section 2.2.2), where tracing the refinement relationship between abstractions over time, and hence the design decisions, can be of great design help. •

Complexity Management – refers to the support for structuring the modeling content for the ease of comprehension. Given that different stakeholders have different concerns and expertise about the system under development, by separating their concerns and using different descriptions, the understandability of the system can be significantly increased.



Reusability – refers to the support for the reuse of previously defined solutions during development. Reusability is closely related to commonality (section 2.2.2) where typing, configuration and generalization help reuse design solutions. In addition, modularity promotes reusability by loosely coupling entities and separating the interface from the internal details. The use of libraries of components from which copies can be made and reused is also a simple reusability mechanism.

2.4. Analysis Context Analysis provides means of verifying and predicting the qualities of the system before it is built. For embedded computer control systems, the satisfaction of design solutions with regard to behavioral correctness, timeliness, reliability, and safety are critical and need to be checked throughout the design. Depending on the type of application and the level of design, the analysis can have varying focus and accuracies, and hence require different kinds of modeling support. In the comparison framework, the analysis context deals with the extent to which different kinds of analysis are explicitly supported by a modeling approach. The following factors classify the quality analysis techniques that are catered for in a modeling approach: •

Functionality – refers to the logical correctness and prediction of behavioral properties of the system, such as analysis of control system robustness and reachability of a state.



Performance – refers to the performance verification and prediction of system properties such as timing, power, and cost. For software-intensive systems, realtime scheduling and performance analysis focus on verifying the scheme for the task execution and communication with respect to timeliness and resource utilization, providing predictions of the system performance. The analysis requires the modeling of software aspects such as tasks, their timing characteristics (such as period, worst case execution time, offset, deadline, release time, priority, and execution modes), and their relations (such as communication, precedence, timeline, and resource-sharing).



Reliability – refers to predicting the consequences of unit or component failures on the entire system by means of probabilistic estimates [69]. In general, the analysis requires models that describe failure modes (such as the omission or commission of a unit), their propagations in the system, as well as the probabilities of their occurrences.



Safety – refers to verifying and predicting the consequences of system failures on the environment. Reliability and safety analysis focus on two closely related but

148

still different quality aspects of system. Reliability is concerned with product quality (measure of the up-time), whereas safety is concerned with the environmental conditions as well (risk to human life). However, reliability is a factor in safety analysis [70]. Safety analysis encompasses both hazard analysis and risk analysis. While the former aims to identify hazards and assesses the levels of hazards in terms of probability and criticality, the latter aims to assess the exposure or duration of hazards on the environmental conditions. The validation of the modeling abstractions so that they conform to the modeling approach’s syntax and semantics can be considered as an analysis technique. However, such analysis relates to the model’s correctness itself, not to the system under development, and will not be handled in this section.

2.5. Language Even though two approaches have the same content, they may differ in the way this content is handled, used and represented in the models. The language factors deal with the techniques and rules adopted by a modeling approach for representing the covered abstractions and their relationships. The major factors are: •

Representation technique – refers to the specification means of abstractions, their properties and relations. These can be divided between graphical and textual representations. Examples of graphical representations are block diagrams, dataflow diagrams, state-machines, collaboration diagrams, sequence diagrams and class diagrams. Textual representations can be descriptive (syntax-free) text, structured text (accompanied with syntax), logical or mathematical equations (differential equations, modal logic, predicate logic, etc.).



Adaptability – refers to the mechanisms available to the user for modifying, extending, and scaling down the modeling language. These mechanisms permit the language to be adjusted to fit user needs more appropriately. It can be argued that once a modification mechanism is defined within a language, it becomes part of the language itself, and hence does not classify as an adaptability mechanism. However, it is generally possible to identify certain user modeling activities that are not directly related to a system specification, but whose outcome leads to different representation techniques that allow a system specification to be performed differently.



Multi-views – refers to whether the complete content is represented using a single model/view, or separate models are used to handle different aspects of the system. This maybe useful for separation-of-concerns, where different stakeholders have different concerns when dealing with the system. Note that in decomposition (section 2.2.2), separation-of-concern is supported by providing a black-box and internal composition representation. In this framework, these representations do not provide two different views of the component, but simply two levels of details, and hence are not treated in this factor. Consistency guarantee – refers to the way of ensuring coherence of redundant information in different views.

149

2.6. Tool Closely related to the language factors, the tools factors attempt to identify the computer-aided techniques and facilities available from a given approach. Certain approaches are tightly coupled with a given tool, in which the approach and the tool are developed together, while other approaches simply define the language, without reference to an implementation, and allow for independent tools to be developed, which may also supply additional features or services. The former is generally the case in many academic approaches where the tool is used to demonstrate or validate the approach, and since the approach has not taken wider industrial acceptance for independent tools to be created. The tool factors need to be resolved for each tool implementation available for a given approach. This may become impractical in the case where an approach has many implementations and where a single representative tool could not be identified onto which the factors could be applied. In this case, it is judged fairest not to apply these factors to that approach. This is the case for the SDL approach where a wide range of tool support is available. More detailed factors that are of interest are: •

Availability – refers to the possibility of obtaining a tool together with issues such as support, cost, legal and financial restrictions, etc.



User interaction – refers to the interaction techniques between the tool and the user such as graphical or textual model representations, dynamic feedbacks and updates, constant consistency checks, constraining actions to ensure correctness, etc.



Tool integration – refers to the interaction with other external tools to provide services that are beyond the scope, or the direct interest of the approach, such as domain-specific tools, analysis tools, graphical tools, simulation tools, import/export facilities, etc.



System Generation – refers to the support for transforming the model abstractions into the end-product, such as software code and processors. System generation depends on whether sufficient information has been collected in the models to allow full or partial execution of the system, highlighting the completeness of information in a given approach. Different generation techniques reach different levels ranging from abstract models such as a finite-state-machine from which code can be further developed, to configuration text aiding the programmer to manually program the system, to programming language code, and finally binary code. The generated code can be either platform dependent or generic and hence be placed on any platform desired.

150

3

Evaluation and Comparison In this section, we present certain interesting comparison factors of the studied modeling approaches. A complete comparison with concise summaries in tabular format is available in [1]. Depending on the reader’s interest, this section can be read in different order. The given order suggests a bottom-up approach by presenting the approaches’ content first, followed by the design context and finally the tool and language support. A more top-down approach is recommended if the details of the comparison are of less interest or previously known, in which case the modeling approaches’ context (section 3.2) should be read first.

3.1. Content 3.1.1. Abstraction Predefined items that represent system constituents categorized as generic, function, software, platform and data abstractions. Tables 1 through 6 present a summary of these abstractions for each of the studied approaches. 3.1.1.1 Generic Two languages provide generic abstractions, allowing for the flexibility of defining other types of abstractions. ACME provides a fixed set of structural abstractions, with genericness through an open behavioral definition. Ptolemy defines a primitive behavioral and structural definition, from which specific models of computations can be extended. In Ptolemy, if the Real-time model of computation (MoC) is adopted, then actors can be treated as software abstractions; in other models of computation, actors are generally functional abstractions. 3.1.1.2 Function Dealing with functional abstractions implies that an approach is working closer to the requirements phase, while most of the studied approaches focus on the computer implementation aspects of the system. For this reason, few approaches provide support for functional abstractions. In addition, with the exception of Orccad and MAST (and possibly ACME and Ptolemy), approaches either focus on software or functional abstractions. MAST deals with certain requirements for its timing analysis. In Orccad, a robot task can be either considered as a functional or software abstraction since it is transformed from the functional to the implementation domain during design. Table 1. A summary of function abstractions Ptolemy (see generic) Lustre None •Agent – structural and behavioral entity that constitute the system Block – defines structural aspects SDL Process – defines behavioral aspects •State – defines a certain state of a process or procedure. Acme (see generic) Wright None Rapide None

151

VCC Orccad Giotto MAST MetaH Unicon

None •Robot task – (RT) elementary robotic control action None •Transaction – set of interrelated event handlers describing part of the system. (system consists of a set of transactions) None None

3.1.1.3 Software Abstractions can be defined at different software design levels from architectural abstractions such as components in Wright, ACME, Rapid and Unicon, to implementation level abstractions such as the multitasking entities (process in Rapid, MAST and Giotto) and finally code related abstractions such as a subprogram in MetaH and a module in Rapid. Table 2. A summary of software abstractions Ptolemy (see generic) •Clock – sequence of times Lustre •Assertion – expression that is always true •Node –structural entity holding behavior. SDL None Acme (see generic) •Component - a localized, independent computational unit. •Computation – the functionality of a component. Wright •Event – basic element in behaviors (e.g., initiate/write and observe/read) that may carry data •Process – combination of events. It is also referred to as patterns-of-events. •Component – a black box at a particular level of detail in an architecture. •Interface – defining a type of module and providing an abstract module of that type. •Module – the implementation means of a component. Executable multi-threaded program – a module of multitasking. Rapide •Process – unit of sequential execution. •Event – activity required/generated by the actions or functions. •Pattern – a set of events with or without causal relationships (i.e. ordering). VCC •Functional component – part of the application, hardware-independent, software. •Module task – (MT) real-time task implementing part of a robot task. Orccad Observer – a MT checking conditions and generating events. •Task – functional unit that executes on a host Giotto •Mode – alternative execution of tasks •Event handler Activity event handler – represents procedure execution or message transmission. Structural event handler – generates and consumes events between event handlers. MAST •Operation – a piece of code or message transmission executed in an activity. (3 types: simple, composite & enclosing) •Scheduling server – a schedulable entity such as a task assigned to a certain processing resource, that executes activities according to a scheduling policy. •Process - single thread of execution & a safe/secure software fault containment partition. (two types: periodic and aperiodic.) •Macro - logical group of processes. MetaH •Mode - alternative run-time configurations of active processes and their communications. •Subprogram - Ada based source code with no persistent data storage, and a single execution entry point. •Package - Ada based collection of executable subprograms and persistent data. •Component – a locus of computation or data in a software system: Module –a compilation unit in a programming language. •Computation –a specialisation of module where only pure computation units (e.g., procedure definitions and calls) are contained. Process – an independent process in an operating system, subtyped into server process and client Unicon process. •SchedProcess –a specialization of process with respect to real-time multitasking. •Filter –a filter process in the Unix environment. General –components or their collections that do not match any of the other pre-defined component types.

152

3.1.1.4 Platform The hardware description in most of the studied approaches is quite simple, with MetaH providing the most detailed definitions. Approaches focus on platform abstractions dealing with the hardware interface from the software perspective (the middleware). Again, this is since these approaches focus on the software aspects. Table 3. A summary of platform abstractions Ptolemy None •Clock – (See software) Lustre Basic clock – shows minimum time grain in the system SDL None Acme (see generic) Wright None •(Hardware module) – processor entity that provides variables (storage) and processing capacity to processes. Rapide Parallel module – a concurrent execution environment. Serial module – a sequential non-preemptive execution environment. •ECU – a container of a specific partition of the software with a scheduling and communication configuration. VCC •Architectural component - part of the base, hardware-dependent, software providing services such as communication or scheduling. Orccad None •Host – executes functionality of tasks and drivers. Giotto •Network – allows communication between hosts. •Processing resource –executes activities processor communication network. MAST •System timer – handles timed events. •Shared resource – resource shared among operations requiring mutual exclusion protection •Processor- computer with single CPU, memory, periodic clock interrupt, I/O, RTOS plus interface to MetaH executive. MetaH •Memory - block of addressable memory. •Device - hardware units that interfaces to other hardware units but cannot host application software. •System - a collection of processors and devices. •Processor – a particular processor in target environment to which a component is assigned. Unicon •Connectors (see communication) RTscheduler – a scheduler in the kernel of a real-time operating system.

3.1.1.5 Data Every language needs naturally to deal with data but certain languages such as Orccad and Rapide do not provide explicit definitions of data. They assume that the data is defined by the target language or follows programming language conventions. In addition, most data abstractions are passive memory holders. Exceptions to this are data variables in Lustre that are associated with time, Abstract Data Types in SDL that have associated behavior (methods and protocols on how a data can be used.) and sharedData in Unicon that define the access protocol to the contained global data. As discussed in section 2.2.1, Figure 4, while data can be generally defined for software and platform, certain data abstractions are specific for communication. SDL and Giotto provide a distinction between data for communication and internal data, while other approaches provide the same abstractions for both. Table 4. A summary of data abstractions Ptolemy •Token – A piece of data sent across a communication channel. •Variable – discrete stream of values of a certain type Lustre •Array – a set of variables. SDL •Data – variable local for each agent.

153

Acme Wright Rapide VCC Orccad Giotto MAST MetaH

Unicon

None None None None None •Port – memory location for data storage Sensor port – updated by environment’s sensor Actuator port – data to drive actuator Private port – task’s internal state. None •Type - Ada based type declaration in source code, or data types of system I/O. •Monitors - shareable package whose data and subprograms’ access by processes must be mutually exclusive; hardware monitors are for system-specific service calls. •Type package - collection of type declarations. •Component (see software): SharedData – a specialisation of module where only global data to be shared among collections of functions and procedures in other modules are contained. SeqFile – a sequential file in a filesystem where lines, characters, or records are read and write sequentially.

3.1.1.6 Communication Certain approaches, such as ACME and Wright, provide an explicit connection abstraction, allowing the flexible definition of specific communication properties and relationships such as commonality and decomposition. In other approaches, communication mechanisms are predefined. Abstractions may also exist for the interface of communication such as ACME, Rapid and Ptolemy ports. MAST does not deal with such abstractions since it does not deal with communication behavior, except for its timing aspects. Table 5. A summary of communication abstractions Ptolemy Lustre SDL Acme

Wright

Rapide

VCC

Orccad

Giotto

154

•Communication channel – allows the sending and receiving of data between actors. •Port – communication interface of an actor None •Signal – holds data exchanged between agents. •Channel – connects agents for signal exchange •Gate – provides an interfacing point for an agent •Connector – interaction among components. •Role – connector’ interface in terms of participants of interactions performed by connectors. •Port – component’ interface in terms of points of interaction. •Connector – an interaction among a collection of components. •Role – the expected behavior of a component that will participate in the interaction of a connector. •Glue - the functionality of a connector. •Port – allows interaction of a component with its environment. •Connection – connecting events and patterns. •Action, Function, and Service –operation primitives in interface by which a component provides and requires interactions with its environment. Action – a "one-way" message sending or receiving. Function – a request/reply function call pair. Service - syntactical grouping of actions and functions. •Behavioral memory – performs the communication between functional components. (2 types: register & bus type) •ECU local memory – allows for broadcast and redundant communication between ECUs. •Bus controller – Provide the containing ECU with access to connected communication network. •Communication network – provide communication between the ECUs. •Data frame – a set of messages packaged together for transmission over a network. (2 types: register & bus type) •Signal – synchronises the operations between robot tasks & robot procedures. (Pre-condition, exception & post-condition types) •Port – allows sending & receiving of typed data to & from MTs. •Driver – communicates data between tasks and modes •Port – (See data) Task input & task output port –data to be communicated to other tasks, or between modes upon mode switch.

MAST

MetaH

Unicon

•Network driver – operations executed on a processor relating to data transmission over network. •Event – raised and consumed by event handlers, triggering other event handlers in the sequence. Internal events - contained within a transaction External events - trigger other transactions. •Connection – established between compatible ports, events and monitors indicating information exchange between software and hardware instances. •Shared memory (See platform) - support communication between hardware units. •Event- interrupt raised and handled by either software programs or hardware units. •Port- statically declared variable in source code, or system I/O. (event port is a combined port and event.) •Channel- hardware for bi-directional point-to-point communication between processors and devices. •Connector – a locus of definition for interactions among components. (Predefined types: DataAccess, FileIO, Pipe, ProcedureCall, RemoteProcCall, PLBundler). •Player – a semantic unit (hook) through which a component interacts with other components. (Predefined types: WriteNext ReadNext; StreamIn, StreamOut; RoutineCall, RoutineDef; RPCCall, RPCDef; GlobalDataDef, GlobalDataUse; ReadFile, WriteFile; PLBundle).

3.1.1.7 System Certain approaches specify an explicit system abstraction. While some are exclusively used for the entire system such as in SDL, ACME, Wright and MetaH, other languages allow such abstractions to be contained inside other lower level abstractions in the decomposition hierarchy such as Rapid and Orccad. The latter approach is more consistent with the concept that a part of a system is a system of its own. For example, if one is to take a component in ACME out of its context, it would not be a valid ACME system. In a sense, approaches that do not explicitly declare a system abstraction better satisfy the concept of systems of systems since they do not restrict that an abstraction needs to have a system abstraction on top. That is, any abstraction can be treated as a system of its own. Table 6. A summary of system abstractions Ptolemy None Lustre None •Agent – (see function) SDL System – defines the top-level structural aspects of the complete system Acme •System – configuration of components and connectors. •Configuration - a complete (software) system architecture in terms of a collection of components and Wright connectors. Rapide •Architecture – an assembly of components, connections, and constraints on the behavior. VCC None Orccad •Robot procedure – (RP) more complex robotic actions or complete robotic application Giotto None MAST None •Application - complete system configuration of software and hardware, specifying the required software MetaH and hardware instances and their connections. Unicon None

3.1.2. Property Simple abstractions such as data types, ports and signals do not possess any significant behavior semantic or structural interface properties of their own. Instead, such abstractions seem to define the properties of their containing abstraction. 3.1.2.1 Structural Interface Abstraction properties related to size, form, input/outputs, etc. Table 7 presents a summary of this property for each of the studied approaches.

155

Structural interfaces can either be simple abstractions, such as data variables and signals, or more complex abstractions, such as ports and roles that may contain their own behavior. Two types of interfaces can be identified: •

Active interface - providing its own behavior semantics. For example, a Rapid interface has a state machine defining when access is given to the internal module; and in Wright, ports of a component have a Communicating Sequential Process (CSP) specifying when access is given to the computation.



Passive interface - specifying only structural interface properties. For example, in MetaH, ports & events are simply data that do not define their own behavior.

In addition, few languages provide a grouping of access points such as SDL’s gate and Rapide’s service. Such grouping can be viewed as a syntactical facility that is useful for complexity reduction. Table 7. A summary of structural interface properties Ptolemy Lustre SDL Acme Wright Rapide VCC Orccad Giotto MAST MetaH Unicon

•Actor – input and output ports for communication. •Communication channel –binary connection of actors. •Node – input and output variables •Array – number of variables it contains •Agent – a set of gates •State – input/output signals •Data – operations allowed on the variable •Channel – input/output signals in each direction. •Component - ports of source or sink type. •Connector - roles of source or sink types. •Component – ports and computation. •Connector – roles and glue. •Component – its interface. •Interface – offered and required actions and functions. •Module – the associated interface. •Events – arguments in the corresponding functions and actions (e.g., the number, order and type). •Functional component – Behavioral memories •ECU - ECU local memories •Robot task & Robot Procedure –input and output signals. •Module Task – input/output port for each required/produced message. •Task – input and output ports. •Mode – input, output and actuator ports •Transaction – input & output external events. •Event handler – input & output events. •Software abstractions - directed external ports, directed events, and shared subprograms. •Platform abstractions - externally visible ports, events, interrupts, and hardware monitors (services). •Components – players (at the interface); •Connectors – roles (in the protocol.)

3.1.2.2 Behavior Semantics What an abstraction does (functional transformation, logic, storage, etc.) and how it generally does it (Model of computation) excluding the more specific properties of activation, persistence, timing and error. Table 8 presents a summary of this property for each of the studied approaches. Behavior can be specified either through implementation-independent techniques such as posets in Rapide, CSP in Wright and any MoC in Ptolemy, or through implementation-dependant techniques such as subprograms in MetaH, modules in Rapide, and functional components in VCC. This highlights the trend of specifying system behavior at a high level with the system automatically constructed into implementation-dependent language that the user does not deal with.

156

Generally, the behavior of computational units such as a node in Lustre or a subprogram in MetaH can be user-defined, while abstractions such as communication channels in MetaH and connections in Unicon have a predefined behavior that at best can be parameterised or the user may chose from a predefined set of options. Languages such as Wright provide full flexibility over the behavior of its abstractions. The manner of describing the implementation-independent behavior of abstractions is predefined in all approaches, and is based on a single type such as posets in Rapide, CSP in Wright, and the synchronous model in Lustre. Ptolemy is an exception, where an actor can be defined using any of the predefined set of MoCs. Table 8. A summary of general behavior semantics properties MoC adapted defines the behavior semantics of the actors and communication channels. •Actor – For atomic actors, generalised as an input to output transformation. (such as a function, state, Ptolemy software tasks, etc.) •Communication channel - generalised as a transfer of tokens between the connected actors. (Such as data communication, synchronization, etc.) •Clock – sequence of time ticks at which associated node or variable have updated values. Basic clock – time tick within which system cannot discriminate among external events. •Assertion – Boolean expression describing known property of the system and its environment. Lustre •Node – given a certain input, produce a certain output at specified discrete time instances. •Variable – infinite sequence of data values over a sequence of times, where the nth value is given at the nth instant of its clock. •Agent – active component with a reactive behavior, responding to input signals. •State – part of the reactive behavior of an agent. SDL •Data – Abstract Data Type (ADT) defined as a set of elements with operations. •Signal – discrete message, possibly with additional data, from a single source to a single destination. •Channel – Asynchronously transfers signals between agents in the same order entered. Acme Not defined (User-defined properties and types can be added, but no semantics support is offered). •Port, role, computation and glue – defined by an associated process. •Component/Connector – either through the decomposition or by processes associated with its ports/roles and computation/glue. Wright The interface parts provide partial specifications. The computation/glue parts define the functionality. •Process – defined by the contained events and their ordering (modality), such as sequencing, recursion, conditionality (i.e., state variables), and alternatives. Events carry data. An event-based language. The underlying model-of-computation is timed posets, where a computation is a set of events generated by the execution of the system. This allows behaviors to be defined using abstract rules (e.g., state and transitions) without implementation details. •Architecture – events interchanged between the contained interfaces through the connections. •Component – given by an interface, or an interface with associated module. •Interface – States and state transitions. A state transition executes a sequence of operations on the current state for an incoming events, or a boolean condition. A state transition is accomplished by Rapide generating some events. •Action – generates a single event. •Function – generates two events (one corresponding to the function invocation and another to the function return). •Connection – generates events for some incoming events. •Module – implements an interface and performs other lower-level operations not shown at the interface (i.e., invisible behavior), like internal DB access, I/O or operating system calls. •Process – executes programming statements in sequence. •Functional component – functional behavior of the application as source code. •Architectural component – functional behavior of the base software as source code. •Behavioral memory –shared memory from which any functional component can read, write, or VCC read/write in a non-consuming fashion. •ECU local memory – ECU memory on which sent and received data frames are placed. •Communication network – Broadcast, static/dynamic arbitration protocols are supported, with the frame transmission and queuing policies. •Robot task – a closed loop control law encapsulated in discrete reactive behavior, producing signals to trigger actions in connected RTs. •Module task – Real-time task with a fixed computational structure of an endless loop of reading inputs, Orccad data processing, and writing output actions. Observer - reactive behavior, producing signals to trigger actions in connected RTs. •Robot procedure – a logical and temporal organisation of discrete reactive behaviors (RTs).

157

Giotto

MAST

MetaH

Unicon

•Task – sequential code, with a fixed computational structure of reading input ports, computation, and updating output and state ports. •Driver – transports and transforms data between ports, given that the guard condition is true. •Event handler – input events triggering its internal operation and/or producing resulting output events. Structural event handler – outputs events are based on input events. The behavior of an event handler is defined through its type such as concentrator, barrier, multicast, delay, etc. •Operation – represents code execution or message transfer with no behavioral description. •Processing resource Network is described using a transmission kind (simplex, half duplex, full duplex) and through its referenced network drivers. Processor implies the hardware as well as the system scheduler •Subprogram – programming logic as Ada-based source code •Process, macro, mode – based on the composing subprograms, their execution paths and communication connections. •Component – partially given by their players, or through behaviors of the contained components and connectors in its composite implementation, or completely given by the source code and data in its primitive implementation. •Connector – partially given by the associated roles and protocol specifications. The implementation is fixed and built into the language.

3.1.2.3 Activation The conditions (data-driven, event-driven, time-driven, etc.) and mechanisms (triggering, autonomy, etc.) of initiation and execution during the abstraction lifetime. Table 9 presents a summary of this property for each of the studied approaches. Three types of activation techniques can be identified: •

Through the interaction with other abstractions such as communication and synchronization. This is exemplified in SDL states and agents, Wright processes and Rapide processes.



External event-based activation such as communication network in VCC.



Time-driven activation such as periodic activation in Lustre nodes and Giotto tasks.

Most languages support hybrid activation in their approach but few allow the possibility of choosing from the different techniques for a given abstraction such as the bus controller in VCC, which can be event- or time-driven. Ptolemy allows any type to be defined based on the chosen MoC. Table 9. A summary of activation properties •Actor – discrete firing, controlled by its director according to MoC, giving a quantum of computation to execute. (For domain-polymorphic actors, there can be more than one MoC.) Ptolemy •Token – once placed by the producing actor, communication channel controls how and when the token is placed on the consuming actor. •Node – cyclic update based on fastest clock of its input variables Lustre •Variable – cyclic update based on its associated clock •Agent & state – activated when an input signal is received, to perform certain actions, change state, SDL output signals, etc. Enabling conditions can be placed allowing or preventing transitions. Acme Not predefined Wright Process – triggered by events. All activities are triggered by events. •Interface – also reacts to boolean conditions. •Module – A module will not fire twice using the same event, although the same event may be used by Rapide different modules. •Process – the execution states are: Ready, Active or Suspended. It is suspended when the process needs an external event or timer expiration to continue execution. •Data frame – time/event driven frames are transmitted according to a statically-defined/arbitration scheme. VCC •Bus controller - time-driven, event-driven, or mixed-mode activation policy. •Communication network – communication initiated by the bus arbiter service.

158

Orccad

Giotto

MAST

MetaH

Unicon

•Robot task – pre-condition signals trigger its starting. Actions are performed as a reaction to input signals, using the synchrony assumption. The occurrence of a ‘type 2 processing’ exception signal causes its stopping, while a new RT is started. •Module task – can be activated periodically, inherit period of another MT by connecting ports, or on an external interrupt. •Task – can only be activated, if containing node is active. Periodic activation, and once activated, cannot be terminated prematurely. (Mode switching may not occur during any task period, unless the task is in the target mode as well.) •Mode – mode switching occurs as soon as the guard condition is executed and is true. •Transaction – triggered by one or more external events and can be periodic, sporadic, singular, unbounded, bursty. •Activity event handler– triggered by one input event. System-timed activities are activated by a system timer. •Structural event handler - triggered by one or more input event. •Operation – activation based on that of containing activity or operation. •Event – depending on the system timer type of the containing processing resource, timed events are activated differently. •Scheduling server – execution controlled by the containing processing resource, which only has one scheduling policy, namely fixed priority scheduling. •Network driver – operations can be either activated when a complete message or each character is sent or received. •System Timer - alarm clock timer causes a hardware interrupt when time of the associated event is reached. ticker timer causes periodic interrupts activating all associated events whose time expired. •Mode– only one is activated at a time when any one of the connected events occur. •Process – activated/stopped when containing mode is activated/stopped. There are predefined scheduling states and transitions, such as stopped, restarting, awaiting dispatching, computing; and mode change, await dispatch call, dispatch, unhandled fault. Processes can be executed in time slices. Aperiodic process – triggered by connected events. If still computing, the process’s behavior depends on whether the event is nudge, signal, or interrupt. Periodic process – dispatched periodically. •SchedProcess Client process – activated periodically by a trigger transferring control from system environment (i.e. a timer interrupt), Server process – executes continuously and receives control only as a result of remote procedure calls. •Other abstractions are activated either by calls or controlled as parts of operating system (e.g., RTScheduler).

3.1.2.4 Persistence The conditions and mechanisms for creation and destruction. Most languages do not actually deal with this issue since they assume a static system. SDL is an exception where an agent can be dynamically created and destroyed. In certain languages such as Giotto and Orccad, it is difficult to determine whether an abstraction is deactivated or destroyed, and hence not possible to determine its persistence/activation property. (What happens to a task, when a mode switches in Giotto? Does it disappear from memory or is it just sitting there waiting for reinitiation?) Since these approaches did not explicitly deal with the issue of persistence, it was assumed that all abstractions are persistent. 3.1.2.5 Timing The timing performance and accuracy (delays, jitters, deadlines, operation times, frequencies, etc.) Table 10 presents a summary of this property for each of the studied approaches. Two types of timing properties can be identified: Timing requirements and actual timing properties. Different languages provide different types or a combination of both. MAST and MetaH are the only approaches that explicitly specify requirements on timing properties. However, in the high level languages such as Rapid and Unicon, their timing properties can only be interpreted as requirements since they do not directly deal with implementation. Both VCC and Orccad do not provide timing

159

properties for their functional abstractions. These properties are provided at the implementation level. Table 10. A summary of timing properties Ptolemy •Actor – Execution duration is controlled by the director (hence the MoC) of the containing actor. •Clock – a counter of events, one of which may be the real time, in terms of discrete time ticks. Events that occur between basic clock ticks are considered simultaneous. •Assertion – value is true at all times. Lustre •Node - Externally, a node’s reaction takes no time (atomic) since all events that occur during reaction are queued until next reaction time. •Variable – temporal operations can be used relating values at different time points. •Agent & state – Time setting and resetting actions can be performed in FSM, producing time-out or SDL alarm signals. State transition take an finite, undefined amount of time. •Channel – FIFO queue mechanism delaying signal transfer for arbitrary time. Acme Not predefined Wright Not defined. •Event – can be timed with respect to one or more clocks and has start time, duration, and finish time. If Rapide no duration is defined, the events are generated infinitely fast. •Clock - monotonically increasing counters which provide a notion of simulation time. •Functional component - ideal-world assumption of zero execution time. •Behavioral memory - ideal-world assumption of zero communication time. VCC •Communication network – Communication delays such as message packaging and transfer latency are handled, as well as bus bandwidth and frame transmission periods. •Robot task – continuous-time assumed initially, followed by implementation timing details specified in Orccad the contained MTs. •Module task – temporal properties such as computation duration and activation period. •Task – periodic execution whose logical processing time (time between reading inputs and updating outputs) is independent of the allocated host. (ensured through compilation.) Giotto •Mode – mode switch possibility checked periodically and takes zero execution time. •Port – periodic update, with zero access time. •Driver – zero execution time •Structural event handler – Zero execution time. Delay & offset event handlers have delay & offset properties. •Internal event – timing requirements such as deadline (soft or hard), output jitter, deadline miss ratio or a combination of the above. •Operation – normalised worst, average & best case execution/transmission times. Actual times depend on the speed of the containing processing resource. MAST •Network driver – the character transmission time is given for a character network driver. •Processor - speed, context switch overheads, and ISR switch overheads times. •Network - packet sending overheads, blocking and transmission times. (worst, average and best cases) •System timer – overhead associated with the servicing of the timer ISR. Ticker timers are also defined with a period. •Subprogram – overheads of source code constructs such as case and if statements. •Process - period and deadline requirements. Execution paths (ComputePath and RestartPath) provide MetaH computation time estimates. •System - dispatchPeriodicTime, dispatchAperiodicTime, IdleFixedTime, and TimeEnforcement •Hardware - clockPeriod, TickDelta & TickRange. RTLoad player – specify the execution-time and period information of each SchedProcess component Unicon including periodicity, and execution-time of source code segments in the primitive implementation of a process (SegmentDef property).

3.1.2.6 Error Non-desired behaviors (states, conditions, etc.) Table 11 presents a summary of this property for each of the studied approaches. Table 11. A summary of error properties Ptolemy Lustre SDL Acme Wright Rapide

160

•Actor – assertions can be specified causing exceptions to be thrown if violated. Not defined •State – unexpected behavior can cause an exception to be thrown by the state. Not predefined Process – failure and refusal events can be specified. (See semantics constraints) •Component/architecture – behavior constraints can be used to define enforced and forbidden events. (See constraints). •Executable multi-threaded programs – Supports exception handlers.

VCC Orccad Giotto MAST

MetaH

Unicon

Not defined •Observer – handles an exception by changing parameters of an MT, killing a RT while activating another, or safely stopping the complete application. Not defined Not defined •SafetyLevel - safety level of an abstraction. •ErrorModel – a Markov-model based error model for an application. •MaskError - fault tolerance voting protocol for mode, macro, process, processor and device. •Operable – operability of mode, macro, system, application given erroneous internal components. •Criticality – ranking of processes, macros and modes for scheduling during a timing fault. •RestartPath & RestartTime – relate to process restart. •ServiceCapability – whether a process restarts/halts a processor. •Status of a port – whether a communication fault is detected at run-time. Not defined

Similar to timing properties, error properties either can describe the actual error behavior such as exceptions in SDL, Ptolemy and Orccad, or can specify requirements on the error states such in Wright processes and Rapid components. Rapide provides both types of error properties, where error requirements are provided at the highest level, with error handling at the lowest level. The closer an approach is to implementation details, the more likely it is to provide specific error definition/constructs, such as in MetaH. The reason is that the designer will have to deal with error behavior as the design nears its final stages, hence requiring better support for error description. 3.1.2.7 Constraints Any limitations on the abstraction such as range, invariants, etc. Two types of constraints mechanisms can be identified: •

A mechanism is provided allowing the user to specify constraints on the structural or behavioral properties of an abstraction. For example, ACME constraints allow structural constraints, Rapide’s assertion rules constrain behavioral properties, and Wright supports both structural (syntactic) and behavioral (semantics) constraints.



Range properties can be provided to constrain the range of a specific property such as timing constraints in MetaH. Such constraints tend to be closer to the detailed implementation level.

3.1.3. Inter-abstractions Relations 3.1.3.1 Decomposition The allowed ways of composing abstractions to form a whole, dealing with encapsulation (The access control to the parts of a whole.), behavior (The implications of composing parts into a whole on behaviors, in terms of lifecycle control, behavior composition, etc.) and constraints (The limitations of composing parts into a whole). Tables 12 and 13 present summaries of these factors for each of the studied approaches. Two different types of decomposition can be identified: structural and behavioral decomposition. In most cases, one type of decomposition implies the other. However, different approaches place more emphasis on one over the other. ACME, Wright, Rapid, Unicon & Giotto focus on the structural decomposition, where the

161

behavior is either ignored (ACME), associated with the parts at each level (Rapid & Wright), or associated at the leaf-level in the hierarchy (Unicon & Giotto). On the other hand, Lustre and MAST emphasise behavioral decomposition where behavior is divided into a set of sub-behaviors. A mixture of structural and behavioral behavior is provided in Ptolemy, SDL, Orccad and MetaH: •

Depending on the MoC, decomposition of a Ptolemy actor can be either structural (Real-time MoC) or behavioral (state-machine MoC). Therefore, the type of decomposition can be intermixed down the hierarchy.



In SDL, a complete structural decomposition hierarchy, where blocks and processes are broken down into sub-blocks and sub-processes, precedes that of the behavioral decomposition, where hierarchical state machines can be defined for each leaf agent.



Compared to SDL, in Orccad, hierarchical behavioral decomposition of robot procedures into other robot procedures and tasks precedes the hierarchical structural decomposition of robot tasks into module tasks.



MetaH provides structural decomposition, with behavioral decomposition of modes into other modes at the top level of the software hierarchy.

Another criterion for decomposition concerns the ownership relationship between the whole and the parts. Two types can be identified: Composition implies that the parts are fully owned/contained by one composite and aggregation implies that the parts can be shared between different composites. From the studied approaches, MAST provides the aggregation of shared resources in operations, while most other approaches deal with composition. The decomposition depth varies between the different approaches. On one extreme, Ptolemy, Lustre, SDL, ACME, Wright, Rapide and Orccad allow their abstractions’ depth to reach any level found suitable by the user. On the other extreme, a Giotto model allows a depth of one where modes can simply consist of tasks. MAST and MetaH provide flexibility for some of their abstractions, (A MAST operation’s decomposition into other operations, and MetaH’s macro/mode decomposition into other macros/modes can reach any depth desired) but are otherwise mostly constrained. It is also worth noting that the decomposition of implementation-level abstractions such as tasks and processes is not generally supported. Concerning restrictions on the decomposition relationships that are supported, the generic feature of ACME implies that it allows the decomposition of components and connectors to any type of components & connectors. Other approaches have a predefined set of allowed decomposition of abstractions to other abstraction types. In addition, with the exception of ACME and Wright, most other approaches do not deal with the decomposition of communication abstractions. This reflects the assumption that communication is to be provided through the implementation middleware. Both VCC and MetaH are integrated with other tools for the support of functionality modeling, namely ASCET-CD and ControlH respectively (section 2.6). Even though these tools support the decomposition hierarchy of the functionality, this feature is not reflected in VCC and MetaH. (VCC keeps record of the hierarchy, but does not make use of it) It seems that since these approaches are focused on implementation, dealing with the functional hierarchy is considered less relevant.

162

Table 12. A summary of decomposition Ptolemy •Actor - composite actor composed of other actors (composite or atomic) and communication channels. •Node – set of internal variables and assertions Lustre •Variable – set of built-in operators, node operators, variables and constants. •Array – set of variables. •Agent – FSM (set of states, actions, etc.), agents, channels, procedures, and local data. System & block - contained agents constrained to processes and blocks. Process – contained agents constrained to processes. SDL •State - Composite state consists of other states, actions, etc. •Data – a set of more elementary data elements. •Gate - signals, remote procedures, remote variables, and exceptions. •Component and Connector – lower-level components and connectors. (One or more decompositions Acme alternatives are supported.) •System –components and connectors. •Component/Connector – one computation/glue. Wright •Computation/Glue – a lower level configuration. •Configuration – components and connectors. •Architecture – components (i.e., interfaces or modules) and connections. •Component – one module (optional). Rapide •Module – (sub-)architecture or (sub-)module, Executable multi-threaded program – any number of processes. •Service – a group of actions and functions in an interface. VCC Not defined •Robot task – a set of connected module tasks. Orccad •Robot procedure – a set of robot tasks and other robot procedures. •Task – private ports Giotto •Mode – set of tasks •Transaction –a graph of connected events and event handlers. •Activity – one operation. •Operation – list of shared resources, and for composite & enclosing operations, other operations. MAST •Scheduling server – list of activity and structural event handlers •Network driver – a scheduling server as well as sending and receiving operations that execute the driver (packet or character) •Processor - system timer. •Macro – processes and macros. •Process – subprograms, packages, monitors, events and ports. •Package/Monitor – types, subprograms, packages, and ports. •Type package – types. •Mode – other modes and processes. (Can be considered as a hierarchical state machine, where the leaves are processes.) MetaH •Application – software in terms of one mode, macro, or process, and hardware in terms of one processor or system. •System – processor, device, and shared memory. •Processor – memory. •(The SafetyLevel of a composite impose certain restrictions on its components. For instance, a composite cannot have a lower SafetyLevel than its components, while primitives may not be assigned a higher SafetyLevel.) •Component – components and connectors in its composite implementation, or some source code or data (external to Unicon) in its primitive implementation. Unicon •PLBundle player – a group of Players. (The connection between two or more PLBundle players is supported by a PLBundler connector).

3.1.3.1.1 Encapsulation An abstraction composed of other abstractions, yet does not have a structural interface, is very likely not to encapsulate its contained abstractions. (Otherwise the contained abstractions would be fully closed from the external world, and hence of no value to the rest of the system.) An exception to this rule is abstractions that can be treated as simple groupings of the contained abstractions for the ease of management of the smaller abstractions, such as Rapid services, SDL gates and Wright computations. (One can argue that such abstractions should not really classify as abstractions because they are simply syntactical groupings) The behavioral properties of such abstractions would simply be a structural combination of the parts’

163

behaviors. There are two encapsulation mechanisms for the containing abstraction’s interface to provide access control over the internal parts to external abstractions: •

Direct access, where the external abstractions are given full access to the internal part through the interface. For example, in SDL/Ptolemy, the agent/actor’s interface simply define which internal signals/tokens are externally available, with no control over access to them, giving external abstractions direct access to the internal parts. In other words, the interface does not contribute any of its own behavior.



Indirect access, where some sort of transformation or control over the internal parts is performed by the interface. For example, in Wright/Rapide, the interface/port of an abstraction controls the timing and method of how access to the external abstractions is given.

Direct access differs from non-encapsulation in that direct access still encapsulates the internal parts and the access is given consciously through the interface. Nonencapsulation implies that the access is not controlled. 3.1.3.1.2 Behavior Semantics In some approaches, it may be the case that the behavioral properties can be specified both at the abstraction level as well as through its parts, such as Orccad robot tasks, Wright components and MetaH components. This over-specification is managed either through the overriding of the abstraction behavior by that of its parts (Orccad and MetaH) or through consistency checks (Wright). Table 13. A summary of decomposition behavior semantics

•Actor The behavior of a composite is defined in the atomic actors. A composite actor may have a different MoC than its contained actor, while all the contained actors Ptolemy must be of the same domain. The director of the containing actor controls the mechanism of execution and communication of its contained actors. When fired, a composite is given a quantum of computation to execute its contained actors and so on down the hierarchy. •Node – Contained variables & assertions’ definitions define the node’s behavior. •Variable – behavior defined through the consisting operators and nodes and their operands. A node is Lustre instantiated for each reference made, and hence two variables using the same node do not conflict over its access. •Array – contained variables have independent behavior. •Agent - Collective behavior of the contained agents, together with its own FSM, determine the SDL behavior. •State – the configuration and connection of contained states and actions determine its behavior. Acme Not predefined Wright All abstractions – behavior composition using the associated processes of contained abstractions. •Component – contained components and connections in the module can compose the behavior. Rapide VCC Orccad

Giotto MAST

164

N/A •Robot task – Composing MTs define the behavior of the containing RT (together with an automaton defining its reactive behavior). The discrete timing properties of the constituting MTs override the continuous timing properties of the RT. •Robot procedure – behavior defined through contained RTs’ behaviors combined with its own automaton. •Mode - Upon mode switch, tasks that belong to both modes continue to execute while new tasks are invoked, and old ones are stopped. •All abstractions - behavior defined through its contained abstractions. Operation – execution time of a composite operation is the sum of contained operations, which is not the case for an enclosed operation.

MetaH

Unicon

•All abstractions – behavior defined by the contained programming level abstractions such as subprograms, packages, monitors, ports and events. The same attributes can be assigned to a composite and its components. The composite’s value will be overriding. Mode – contained modes and processes are activated/stopped when the containing mode is activated/stopped. •Component – behavior defined by the contained components and connectors. •PLBundle player – behavior determined by the contained players.

3.1.3.2 Communication The allowed ways of connecting different abstractions for the exchange of items (information, energy, material, etc.), dealing with the behavior description of connections, implications on the connected abstractions (initialisation, arbitrations, flow-control, timing, error, etc.) and the limitations of connecting abstractions. Table 14 presents a summary of the behavior semantics factor for each of the studied approaches. Approaches differ in the level of details at which communication is supported: •

Approaches such as Lustre, SDL, Orccad, Giotto, MetaH and Unicon, which support the lower end of the implementation levels (medium and detailed design), tend to provide quite specific communication services such as message passing, shared memory, etc.



VCC provides a high level of communication (instantaneous communication through behavioral memory) for functional components, with lower level details for the communication network. Rapide also provides high-level communication description using implementation-specific communication primitives (actions and functions).



More general approaches, such as Ptolemy and Wright, provide high level description of communication, without reflecting on the implementation techniques.



ACME provides a structural description of the communication, without dealing with the semantics, allowing it to be used for any purpose. Approaches differ in the communication protocols supported, and whether these can be further extended or redefined:



Ptolemy’s communication protocol is fixed, based on the chosen MoC.



Lustre’s communication protocol is predefined based on the ‘synchronous paradigm’. (All events occurring during a system reaction are considered simultaneous, and a reaction is assumed to be atomic.)



SDL has predefined asynchronous communication, with synchronous remote procedure call.



Wright allows the user to define the behavior of the communication.



Rapide supports predefined synchronous or asynchronous communication.



VCC assumes instantaneous communication between functional components, and a communication model between ECUs that provides some flexibility through the definition of different arbitration policies, queuing and delay properties.



Orccad assumes message-passing communication with a set of predefined protocols to choose from.

165



Giotto provides a predefined communication protocol (non-consuming, unit delay buffer).



MetaH provides fixed communication protocols to choose from: messagepassing, shared variables. Hardware communication is fixed communication via memory sharing or point-to-point channels.



Unicon provides predefined communication protocols that can be configured by the user. Table 14. A summary of communication behavior semantics

Controlled by the receiver in communication channel, which provides the mechanism of handling the Ptolemy transport of tokens from the output to the input port. (FIFO queue on the input, global queue of events, etc.) Lustre The internal & output variables are defined through the connected node’s outputs. Channels convey asynchronous communication of signals (except remote procedure calls that form SDL synchronous communication.) which are handled in an unbounded FIFO queue. Acme Not predefined The connector’s process determines the protocol by communicating events in the components’ Wright processes. The events carry data. •A connection, when triggered by an incoming event, will output another set of events according to the specified rule. There are three types of connections. Basic connections – connected events are equivalenced. Pipe connections – ordering of input events is preserved in the output events upon repeated firings. Agent connections – ordering of input events is not preserved in the output events upon repeated Rapide firings. •Actions and functions carry data. Actions – for asynchronous interaction (corresponding to a signal semantics). Functions – for synchronous interactions (corresponding to a question/answer semantics). Connections between functional components imply instantaneous communication, while connections VCC between ECUs involve arbitrations, queuing and delays. Module tasks – communication via message-passing. Eight different predefined mechanisms can be specified such as asynchronous, synchronous, asynchronous producer-synchronous receiver Orccad communication. MT uses send & receive operations to access ports irrespective of communication mechanisms used or connected MTs. •Port keeps current value until updated even if already read by tasks, and new port values are not Giotto available to other tasks until the end of the source task’s period. (Unit-delay value propagation) •The worst case transfer time depends on the particular network the transfer occurs on. MAST N/A •Port & event connections – A process or a platform abstraction starts sending either upon completion (immediate connections), or at its deadline (single sample delay connections). In the case of Immediate connection, the processes should have harmonic periods. Equivalence connections - managed by monitors at source code level, supported by a semaphore protocols of a processor. Equivalenced connections should have matching internal and external definitions. MetaH •Software communication is time deterministic, ensured by the executive. •Hardware communication via point-to-point, contention-free channels, by means of buffers. Routing is managed by the executive. Timing is deterministic and characterized by a set of timing attributes. The communication protocol is predetermined and cannot be extended or modified. •Communication errors are detected and handled by the system platform. •Connectors establish the rules/protocols of interactions, predefined through the type definitions. RemoteProcCall connector – based on a synchronous client-server style. Unicon Additional information can be associated to a connector using properties, such as timing or ordering of interaction.

With the exception of ACME, Unicon, Rapide and Wright, most approaches do not support the user specification of constraints on the structure or behavior of communication. ACME and Unicon provide structural constraints specifying the number and types of connections allowed. Rapide provides behavioral constraints specifying forbidden and enforced communication patterns. Wright provides structural constraints on the topology, as well as behavioral constraints. The timing properties of communication are handled differently with different approaches. In certain cases, time-determinism is ensured by the underlying implementation, such as the executive in MetaH, and the unit-delay communication offset in Giotto. In Rapide, the communication behavior, specified using timed166

posets, can be further analyzed to determine its timing properties. 3.1.3.3 Synchronization The allowed ways of relating different abstractions for synchronization and concurrency (multiprocessing, multitasking, etc.), dealing with the behavior description of synchronizations, implications on the related abstractions (initialization, precedence, blocking, scheduling, parallelism, error, etc.) and the limitations of synchronizing abstractions. Table 15 presents a summary of the behavior semantics factor for each of the studied approaches. There are different ways to handle the order of execution: Sequential execution implies that abstractions have a precedence relationship between them where an abstraction executes to completion before the proceeding abstraction starts. Abstractions can be concurrent where they execute simultaneously. Finally, alternate execution implies that abstractions alternate between their executions, whereby an abstraction does not necessarily terminate before another abstraction starts executing. •

Lustre, Wright and VCC provide only one order of execution, namely concurrency for their nodes, components and ECUs respectively. Similarly, Giotto and Unicon provide alternating/multitasked for their tasks and processes. In other approaches, the type of execution order either depends on the type of abstraction, or can be specified by the user.



MAST and MetaH provide no user choice. MAST transactions are concurrent, while scheduling servers are alternating/multitasked, and operations are sequential. MetaH’s processes are alternating/multitasked, processors are concurrent, and paths specify the sequential order of abstractions.



Other approaches provide user choice. Ptolemy actors can be concurrent, sequential or execute alternately depending on the MoC, while SDL agents are concurrent or alternating execution depending on the containing agent type. Rapide processes can be either sequential or alternating/multitasked. Orccad’s robot tasks and robot procedures run either concurrently or in sequence. (Rapid and Orccad do not provide user choice for other abstractions. Rapide interfaces are concurrent, and Orccad module tasks are alternating/multitasked.) Table 15. A summary of synchronization behavior semantics

Ptolemy Lustre SDL Acme Wright

Rapide

VCC Orccad

the director controls and synchronises between actors, according to its MoC. (In the CSP MoC, actors are executing concurrently and connecting channels act as rendezvous communication mechanisms.) data-dependencies provides synchronization constraints between nodes and output of a node is instantaneously broadcasted to all other nodes •agents contained within a block are concurrent, while agents within a process have alternating execution. •State – the state machine defines the flow of control from one state to the other. N/A •Components are concurrent except that they are coordinated by communicating events. •Sequencing defines the precedence of processes/events in a process. There are two operators: “-> “ operator (e.g., e ->P first engages in the event e and then behaves as P) and “;” operator (e.g., P;Q behaves as P until P terminates successfully and then behaves as Q) •The ordering is based on posets. Time order – specified with respect to local clocks. No supports for global clock. Causal order – specified with respect to logical dependence relation of events. •Parallel modules provide multitasking execution environment for processes. serial modules provide a "one-at-a-time" non-preemptive execution to its processes. This means that once a process is running, it will run forever or until it yields control using its reactive statements. ECUs are truly concurrent. Automata, based on a synchronous language, is used to synchronize between RTs, RPs & MTs via signals.

167

Giotto MAST

MetaH

Unicon

Multitasking environment of the tasks ensures that each task executes to completion before the end of its period, at which point its output is produced. •Scheduling server – execution controlled by the containing processing resource, which can only be fixed priority scheduling. The contained activities share the same scheduling policy such as interrupt service routine, preemption, polling. •System platform schedules periodic processes using preemptive RM scheme. It also controls the executions of software abstractions. •Processors are truly concurrent. Clock synchronization is specified by ClockJitter, ClockPeriod and ClockSyncTime, etc. Scheduling policy is predetermined for all processes except for SchedProcess where one of six predefined algorithms can be chosen by the user: rate monotonic, deadline monotonic, earliest deadline first, FIFO fixed priority, round robin fixed priority, timesharing algorithm. ( A RTScheduler connector controls the execution according).

Except for the case of sequential execution, abstractions may wish to interact and coordinate their execution, whereby one waits for the other to reach a point in its execution before proceeding. This interaction can use the same mechanisms as that for communication interaction, with the difference that the communication is for the intention of coordination and not the exchange of data. Ptolemy, SDL, Wright, Rapide and Orccad provide such synchronization, while VCC, Giotto, MAST, MetaH and Unicon do not deal with it. MetaH also deals with the synchronization of the hardware processors, which is not observed in other approaches. Both Rapide and Wright do not differentiate between communication and synchronization, and hence the same mechanisms, as well as constraints, are adopted for these relationships. 3.1.3.4 Commonality The relations between abstractions with respect to their types and variants. Table 16 presents a summary of this relationship for each of the studied approaches. Commonality is handled through the typing mechanism in SDL, Rapide, ACME, Wright, and MetaH. These approaches differ in that SDL and Rapide also support specialisation/generalisation, with ACME and Wright supporting both specialisation/generalisation and common configuration as well. Table 16. A summary of commonality Ptolemy Domain-polymorphic actors used in different domains share certain common behavioral properties. Lustre Not defined •Types of agents, states and interfaces are supported from which instances sharing the same structure and behavior can be created. SDL •The generalisation/specialisation of a sub-type from a super-type allows the definition of a new type from another by adding agents to the super-type or by refining virtual types in the super-type. •Type definitions of abstractions can be defined, from which instances are created. (type of Acme configurations is called family) •Types can be extended, defining new types. •Type definitions of abstractions, from which instances can be created. Interface type – instantiated either as the port of a component, or as the role of a connector. Wright Style – type of configurations. The common properties include a common vocabulary (component and connector types) and restrictions on the ways this vocabulary can be used in configurations. •The definitions can be extended, defining new types. •Reference architecture – express common behaviors and behavior constraints. New architectures and their computations can be checked for equivalence with the reference architecture by defining a map. •Type definitions of components and services. Rapide Interface type – define a type of component. •Component types can be subtyped. •Modules can have code inheritance. VCC Not defined Orccad Not defined Giotto Not defined MAST Not defined Type definitions of abstractions, from which instances are created. A type is defined by specifying its MetaH internal and external properties. Unicon Not defined

168

3.1.3.5 Dependency The relations between solutions in general (dependency, end-end trace) Dependency seems to have weak support in the approaches studied. Rapide provides a mechanism where a service definition is accompanied with a dual service definition. This mechanism ensures that the assumptions of a service about its connected counterpart are correct when connecting services between components. 3.1.3.6 Refinement The mapping of abstractions to other abstractions for solution details. Table 17 presents a summary of this relationship for each of the studied approaches. Wright is the only approach where an abstraction can be indefinitely refined into other abstractions. Other approaches establish a fixed relationship between an abstraction and its refined counterpart such as the refinement of a Rapide interface connection architecture to multi-thread programs. Ptolemy Lustre SDL Acme Wright

Rapide

VCC Orccad Giotto MAST MetaH Unicon

Table 17. A summary of refinement

Not defined Not defined Not defined Not predefined (rep-maps and representations can be used for refinement) Behavioral refinement – A process refines another process if obeying its behavior rules. •Architecture – refined through the refinement of its components and connections, going from an interface connection architecture to executable multi-threaded programs. Component – refined from interface behavior (reactive rules), to internal structure (subarchitectures), to module implementation in detailed programs with given procedural language constructs. Connections – refined from abstract behaviors to implementation modules. •Module substitution – If a module has an interface that is a subtype of another interface, then it can substitute any module with the super type interface. No info (concerning the specification of timing properties of a functional component, once allocated to an ECU) •Robot task - The continuous-time RT definition is further refined into an implementation definition when specifying the constituting MTs. Task - further refined with implementation details such as WCET, once allocated to a host. •Transaction – refined into scheduling servers or network drivers. •Multiple partial specifications of the same object can be defined and related for refinement. •Once allocated, restrictions apply to source abstractions such as in terms of properties StackSize, HeapSize, and SourceDataSize. Not defined

Generally, abstractions are refined into other abstractions of the same type. In some cases, abstractions can be refined into other types of abstractions, such as transactions in MAST and components in Rapide. In addition, refinement can be performed relating abstractions at different design levels. (Section 2.3) In Rapide, for example, component and connection definitions at the architectural level are refined into modules at the medium-level design. 3.1.3.7 Allocation The mapping of software abstractions to platform/hardware abstractions. Table 18 presents a summary of this relationship for each of the studied approaches. VCC, Giotto, MAST, MetaH and Unicon support distributed computer architectures. However, Unicon does not support the explicit allocation of communication on the

169

network. In addition, MetaH is the only approach that provides the facility of specifying certain constraints on the possible allocations in the system. The allocation of software to platform/hardware abstractions is generally performed together with some refinement. In certain cases, this may be due to the need to refine an abstraction in order to suite the allocation. In Giotto, once a task is allocated to a processor, further details such as the worst-case-execution-time of the task need to be specified. In MetaH, source abstractions are further refined with properties such as sourceDataSize, once allocated. In MAST, a transaction is refined into scheduling servers, which are allocated to a processor. Approaches that support allocation with no further refinement, such as Unicon, normally treat the allocation process as a compilation directive where the designer does not need to be concerned with the details. Table 18. A summary of allocation Ptolemy Lustre SDL Acme Wright Rapide VCC Orccad Giotto MAST

MetaH

Unicon

Not defined Not defined Not defined Not predefined Not defined Software modules or interface can be allocated to either parallel or serial modules. •Functional component, memory, architectural component & bus controllers – allocated to ECU •Behavioral memory – allocated to data frame, once the functional components are mapped to the ECUs Not defined •Task – allocated to a host •Port - connection allocated to a network •Scheduling server – allocated to processor •Network driver – allocated to network •Mode, macro – allocated to processor or system if the processor or system is contained in the application. •Process & subprograms – allocated to processor. A process and its components should be inside a single memory partition. In the case of equivalence connection, the processes can only be distributed to different processors that share a physical memory. In the case of Immediate connection, the processes should run on a single processor. •Binding and AllowedBinding – property specifying the set of platform/hardware abstractions to which a process, monitor, package, subprogram, or connection is allocated. •Component - allocated to a particular processor.

3.1.3.8 Criticality and Replication The relations between abstractions with respect to safety constraints and duplicated abstractions, respectively. Besides MetaH, no approach deals with this issue. MetaH allows for the specification of relative criticality of abstractions in the system. No approach provides a general mechanism for dealing with replication. VCC provides specific replication of its communication structure as well as some of its functionality (redundancy policy)

3.2. Design Context 3.2.1. Levels, Activities and Disciplines The degree of support for the different design levels (functional, architectural, medium-level and detailed design), the different engineering disciplines

170

(Mechanical, control, software, electronics, power, etc.) and for structuring and behavior design at the different design levels. Figure 5 and table 19 present summaries of these factors for each of the studied approaches.

( '

)

&

#

"

%

$

!

Most approaches focus on the software development, except for VCC and MetaH that deal with the hardware architecture and middleware. Ptolemy and Lustre are dedicated for the behavior design of the system, while ACME is dedicated for structure. All other approaches support different aspects at different levels during development. Figure 5 illustrates the design levels covered by each modeling approach.

Figure 5. Design levels focused on by each modeling approach. The approaches studied are mainly developed from the software and computer science community. For this reason, software development becomes a focus of these approaches, as mentioned above. Table 19. A summary of design activities Ptolemy Lustre SDL Acme Wright Rapide VCC Orccad Giotto MAST MetaH Unicon

Behavioral design of functionality, with structural breakdown of the behavior to support multiple models of computation. Behavioral design of reactive program, with some structuring through hierarchical nodes. Structural breakdown of functionality, with behavioral design of processes. Structural design (external languages & tools for behavioral design) of software architecture Structural design of software architecture and behavioral design the parts Structural design of software architecture and behavioral design the parts Structural design of hardware architecture, plus the allocation of software to hardware Structural design of mission architecture, and behavioral design of the parts. Structural design of system into modes and tasks, with behavioral design. The allocation of software to hardware is also supported. Structural design of activities into tasks with behavioral design of real-time aspects. The allocation of software to hardware is also supported. Structural design of application into software and hardware architectures, with behavioral design focusing on real-time and reliability aspects. Structural design of software, with scheduling support.

3.2.2. Methodology The degree of support for specific design process (prescriptive/descriptive, implicit/explicit, generic/detailed, suggested stakeholders). Table 20 presents a summary of this factor for each of the studied approaches. 171

Most approaches can be used independently of any specific design methodology. Exceptions to this are Rapide and Orccad, where a certain design workflow is assumed in the language definition. VCC, on the other hand, suggests a development process. Table 20. A summary of design methodology Ptolemy Lustre SDL Acme Wright Rapide

VCC Orccad Giotto MAST MetaH Unicon

Not defined Not defined Not defined Not defined Not defined Evolutionary development: •A system is first defined as an interface connection architecture. •Executable modules are introduced as replacements for each interface and connection. •At each step the new version of the system can be simulated and analyzed to see if it still conforms to its constraints. A design workflow suggested giving an ordered set of steps for constructing each model, performing design decisions and analysis. Bottom-up approach suggested starting with continuous-time control law design to implementation details and more complex missions. Not defined Not defined Guidelines for programming Ada and C are provided. Not defined

3.2.3. Traceability The degree of support for identifying and managing interdependencies of information and design decisions over time (Relates strongly to refinement). Table 21 presents a summary of this factor for each of the studied approaches. Traceability is closely related to the refinement relationship. With the exception of Giotto’s refinement of a task with implementation details, which is not traced during the design, other approaches provide specific mechanisms for the tracing of design changes and refinements such as rep-maps in Acme, and partial specifications in MetaH. Table 21. A summary of design traceability Ptolemy Lustre SDL Acme Wright Rapide VCC Orccad Giotto MAST MetaH Unicon

Not defined Not defined Not defined The refinement history can be supported through rep-maps & representations (See refinement) Traceability of behavior refinement is supported through the decomposition relationship. (See refinement) Explicit mapping between architectures or components (maps and binding) supports the correspondence between high-level and detailed design. (See refinement) Not defined (Communication is gradually refined but this refinement history is implied in the process but not stored within the system) Not defined Not defined The activity common between a transaction and a scheduling server acts as the indirect traceability link between them. Traceability of changes in object specifications is supported through partial specifications. (See refinement) Not defined

3.2.4. Complexity Management The techniques of structuring the content for ease of comprehension. Table 22 presents a summary of this factor for each of the studied approaches. 172

The major identifiable mechanisms for complexity management are: •

Hierarchical decomposition and encapsulation, reducing complexity through information hiding as shown in Ptolemy, SDL, MetaH, etc. (section 2.2.2)



The use of domain-specific concepts provides the user with familiar terminology. This is the case in Orccad where the use of separate modeling entities for robot procedures and robot tasks is needed since they have different semantics and to satisfy the robot community terminology. A more general approach would combine these two concepts without any loss of expressing power, yet provide simplicity of the language.



The use of a few, but central concepts reduces complexity by maintaining the conceptual integrity of the system such as the component/connector concept in Acme, Wright and Unicon, as well as the use of a universal model of interaction in Ptolemy.



Good language and tool support through graphical representation and multiple views facilitates the accessibility and structuring of information, such as Ptolemy, SDL, etc. (section 2.5)



The use of different modeling abstractions for different aspects of the system facilitates the separation-of-concerns. For example, SDL provides different constructs for the modeling of structural and behavioral aspects of the system.



Traceability support or simple successive refinement where the trace is recorded reduces complexity as shown in ACME, Giotto, MAST and MetaH.



Commonality mechanisms (section 2.2.2) such as typing and specialisation/generalisation, reduces the work effort and the introduction of errors by preventing the need to reinvent previously designed entities as shown in SDL, ACME, Wright, Rapide and MetaH. Table 22. A summary of design complexity management

•The possibility to use different MoCs permits the usage of the most suitable means to describe the system. •The hierarchical decomposition in which only one MoC is used at any one level simplifies the Ptolemy understandability of the model. •The universal model of interaction between actors, irrespective of their contained MoCs, simplifies their interaction definition. •Graphical representation •The use of nodes as operators within other node definitions forms a node hierarchy allowing the design of complex functionality. (See decomposition) Lustre •Arrays and recursive nodes simplifies the code needed in defining nodes. •Graphical representation •The hierarchical structuring of the system and using separate diagram for each agent and composite state in the FSMs, preventing the state explosion problem. SDL •Structural and behavioral aspects are separated into different abstractions. •Support typing and generalization/specialization •Graphical representation •The use of general system concepts such as components and connectors. •Hierarchical decomposition Acme •Representations allows traceability and the use of multiple views. •Support typing and generalization/specialization •Graphical representation •The use of general system concepts such as components and connectors. •Hierarchical decomposition Wright •Support typing and generalization/specialization •Behavior can be specified at a higher level, hiding the internal decomposition behavior.

173

Rapide

VCC

Orccad Giotto MAST MetaH Unicon

•Support typing and generalization/specialization •Behavior can be specified at the interface level, hiding the internal decomposition behavior. •Hierarchical decomposition •Graphical representation •The independent views of software functionality and the computer architecture helps in the separation of concerns. •Graphical representation •Hierarchical decomposition •Graphical representation •While convenient for robotic-domain users, robot tasks and robot procedures share similar syntax, yet have different semantics. •The lack of hierarchical decomposition of the system increases complexity for large systems. •Successive refinement of logical tasks with timing details. •The almost flat structure of the model hierarchy increases the complexity. •Refinement from transactions to scheduling servers. •Hierarchical decomposition •Graphical representation •Support typing •Successive refinement from partial to more complete specifications. •Hierarchical decomposition •Graphical representation

3.2.5. Reusability The degree of support for creating and integrating reusable standalone components (previously developed solutions, COTS). Table 23 presents a summary of this factor for each of the studied approaches. There are three common techniques to facilitate the reusability of entities: •

The use of commonality mechanisms such as typing and generalisation/specialisation relationships (Section 2.2.2) covers the most common approach for reusability.



Good encapsulation such as interface definitions in ACME components and the use of middleware in MetaH promotes the reusability of these entities.



The use of libraries and templates is a good mechanism for storing and reusing previously designed entities. Table 23. A summary of design reusability

Ptolemy Lustre SDL Acme Wright Rapide VCC Orccad Giotto MAST

174

Actors can be designed to be domain-polymorphic or data-polymorphic, allowing the reuse of the actors inside actors of different domains. Node definitions allow the encapsulation and reusability of functionality. •Use of typing and generalisation/specialization. •Library packages allow the sharing of abstractions across projects. •Procedures allows the reuse of recurring behavior. •Use of typing, generalisation/specialization and templates •Separation of interface specification from internal details. •separation of interface specification from internal details •Use of typing, generalisation/specialization and styles. •separation of interface specification from internal details •Use of typing, generalisation/specialization. •Implementation library is available The UCM provides a common basis for all communication protocols, with its user parameterisation providing a good degree of reusability. •Library allows for the reuse of previously defined robot tasks. •The use of standard communication operations between MTs allows their reuse in different RTs. Not defined Not defined

MetaH

Unicon

•Use of typing, but types cannot be specialized into new ones. •Separation of interface specification from internal details. However, properties that are important for compatibility such as timing and error are defined internally. •Reverse engineering is supported by providing tools for “white-box” integration and compliance check. (ControlH) •Middleware for platform adaptability and portability (a limited numbers of variants.) Separation of interface specification from internal details.

3.3. Analysis Context The means of supporting the verification and prediction of system qualities such as functionality correctness, performance, reliability and safety. Table 24 presents a summary of this factor for each of the studied approaches. Table 24 presents a summary of the available and possible analysis techniques provided by each approach. Available analysis techniques are those explicitly identified, and to which some support is given through built-in or integrated tools. However, given the content supported by an approach, it may be the case that other analysis can be potentially performed, which has been ignored or discarded by the developers. Note that since SDL has many tools implementations, it is not possible to discuss its provided analysis support, but one can instead discuss the possible analysis techniques. Table 24 Summary of available ( ) and possible (+) analysis techniques Functionality Model Simulation Checking

Performance Model Simulation Checking

Timing

Reliability Safety

Ptolemy Lustre SDL

+ +

+ +

+

Acme Wright Rapide

+

+

VCC Orccad

+

+ +

Giotto MAST

+ + + + Simulation analysis seems to be the easiest analysis technique to support, limited to particular scenarios that are considered. As long as the behavior information is available, it should be possible to execute this behavior in a virtual environment. Simulation does not necessarily have to be at a high description level, it can be the case that the final implementation of the system is simulated/debugged before testing the final product. In Rapide, simulation of the behavior is at the higher level, compared to MetaH and Unicon where the simulation executes the actual final code. In addition, if timing properties are available, then performance simulation or schedulability analysis should also be possible. MetaH

Unicon

Model checking analysis can only be supported by those approaches that have some formal representation technique, which is used for either functionality or performance analysis.

175

MetaH is the only language that supports reliability analysis. All other languages do not deal with the error probabilities in the system, and hence cannot perform such analysis. Similarly, no language deals with safety analysis since even if the error probability is handled in the approach (MetaH) they do not deal with the severity/hazard of this error.

3.4. Language 3.4.1. Representation Technique Techniques supporting the specification of abstractions, their properties and relations. (Text, graphical, formal, mathematical, state-machine, logic, blocks & lines, etc.) Table 25 presents a summary of this factor for each of the studied approaches. A graphical user interface is becoming the more generally accepted tool interface allowing the user to implement the models using graphical representations. A simpler interface is a textual editor in which the user writes the definition of its models using text with a predefined syntax. Ptolemy, VCC and Orccad mainly provide graphical representations, with some textual parts for the representation of properties. Except for VCC, these approaches support a hierarchical breakdown of the diagrams. Lustre, Wright, Giotto and MAST provide a simple textual representation, with the former three approaches having a mathematical behavior description. Finally, SDL, ACME, Rapide, MetaH and Unicon provide an interchangeable graphical and textual representation. Table 25. A summary of representation technique Ptolemy Lustre SDL

Acme

Wright

Rapide VCC

Orccad

Giotto MAST MetaH Unicon

176

Hierarchical graphical block-line diagram specifications with textual specification of properties Textual specification •Mathematical expressions specify behavior Hierarchical graphical (SDL/GR) block-line and state machine specification or a textual (SDL/PR) specification. •In graphical format, items such as expressions, data definitions are also given in textual format. Hierarchical graphical specification using different icons for different objects, or textual specification •The icons can be defined and modified by users. •Logic formalism (Open Semantic Framework) specifies structural consistency and completeness constraints. •Textual specification CSP (Communicating Sequential Process) notation specifies behavior (events and processes). First order predicate logic specifies structural and behavioral constraints. Hierarchical graphical and textual specification •Different sublanguages specify different aspects of system description. (Type language, architecture language, specification/constraint language, pattern language, and executable language.) •Poset-based rules or code based on executable language specify behavior and their constraints. Graphical model •Textual programming code (C/C++) specify behavior •Hierarchical graphical block-line specifications of MTs and their connections. •Graphical state machine specify reactive behavior of RTs. •Graphical state machine or textual specification specify reactive behavior of RPs. •Textual mathematical equations specify continuous behavior of RTs. •Textual C/C++ source code specify discrete behavior of MTs. Textual description •Programming code specify behavior Textual description •Textual references specify relations (such as decomposition) between abstractions Hierarchical graphical or textual specification •Source code (such as Ada) specify behavior Hierarchical graphical specification or textual specification. •Programming source code specify behavior

A summary of the language sub-factors is presented below: Adaptibility – ACME provides a high level of adaptability by focusing on the system structure, while avoiding the definition of any semantics, and leaving the interpretation of entities and their properties to the user. ACME and Unicon allow the user-defined properties to be added, which are not interpreted by the approaches. Ptolemy however provides a foundation for the behavior description that can be extended into any model of computation desired. Another way of allowing language adaptability is integrating another language for the definition of new elements such as the definition of new data types in Lustre and SDL, as well as executable language constructs in Rapide. Multi-views - Most approaches provide a single view of the system, except for ACME, VCC and MetaH. While VCC and MetaH have a predefined set of views, ACME provides a mechanism for the user to define different views for each component or configuration, where the consistency is provided through predicate logic. There is no need for consistency guarantees in the other approaches since information is not duplicated in different views.

3.5. Tool General features of the tool such as support for documentation, analysis, maturity, community acceptance, etc. The SDL approach is excluded from this section since there are multiple tools that implement it, which may provide different supports and techniques. It hence becomes difficult to make an overall judgement on the approach’s tools. A summary of the tool sub-factors is presented below: Availability - Being academic tools, Ptolemy, ACME, Wright, Rapide, Giotto, MAST, Unicon are freely available, with source code access for most of them. VCC is a commercial tool, while Lustre is available both as a commercial as well as an academic tool. Finally, Orccad and MetaH are currently not available and have limited availability. User Interface - Besides the user interface for the modeling of the system, which is dealt with under the language factors, there are two other types of interactions between the user and the tool. First, the user needs to have control over certain activities in the tool such as the analysis and validation activities. For example, Ptolemy provides graphical control over the simulation steps, and in approaches such as Rapide and ACME validation checks are performed upon user request. Second, the feedback of analysis results to the user can be provided in different ways such as 3D animation in Ptolemy. Tool Integration - Generally, approaches tend to integrate other tools in order to cover certain aspects that are weak or not covered in the original approach. For example, MetaH is integrated with ControlH for the functional description of its subprograms, and Giotto uses Simulink for the graphical representation. Certain approaches become quite dependent on this integration for it to be usable. For example, Wright needs to have a CSP checker to perform any kind of analysis. On the other hand, MetaH can still be operable without the use of ControlH.

177

System Generation - Most language support the automatic generation of software. Again, ACME and MAST focus on special aspects of the complete system, and hence are not able to perform any code generation. Wright generates a CSP description of the system, without dealing with the final implementation.

4

Conclusion As part of a larger effort to develop a better understanding of complex embedded control systems and model-based development, a study of a set of modeling approaches was carried out. For this purpose, a framework for the characterisation and comparison of modeling approaches was developed by combining generic system concepts together with concepts discovered during the study. The framework focuses on the modeling content and features that are specific to model-based design and analysis activities. In addition, modeling techniques, and tool support are studied. Iterating between a framework definition and evaluation through the application of particular modeling approaches evolved and stabilised the framework, consolidating more precisely the defined factors. The choice of approaches covering different levels of design and disciplines ensured that many aspects of the modeling and development process are covered. The resulting framework is quite reasonable and practical for comprehending and comparing the studied modeling approaches. The survey performed in this report helped discover common concepts and patterns, as well as unique ones. In future work, these concepts would be the basis for further refinement of the framework, by introducing new factors and sub-factors that define and categorize them in a standard way. For example, the classification of structural interfaces (section 3.1.2.1) into passive and active interfaces could be a potential subfactor of the structural interface property in a more detailed framework. In addition, the application of other modeling approaches would further validate and stabilise the framework, as well introduce new concepts that have not yet been discovered. The current survey is based heavily on approaches with a main focus on the software aspects of the systems. While other domains are touched upon, new concepts and factors can best be introduced by applying the current framework on approaches with a focus on other relevant domains such as control, hardware and mechanical engineering. Such study would also help unify and standardise common concepts that are shared across all such domains. It is also necessary to develop more objective definitions of the modeling abstractions so that the description of a certain modeling approach can be performed independent of the terminology, notations and representation techniques adopted in the approach. It was originally intended to perform such an objective definition, given that one of the main aims was to study ‘what’ each approaches tried to model, without consideration for ‘how’ this was performed. However, it was later discovered that the difference between the content and its representation techniques is often blurred. Experience needed to be gained first through an initial survey, before the content definition can be deduced out of the studied language definitions. The strategy was hence to perform a study where we allow each language to define its own content. Given these definitions as a reference, the content can then be ‘purified’ to deduce the more objective content definition. This new definition can then again be used for performing the study of the same languages. Only then can the 178

separation between the content and technique be possible. One can view the categorization of abstractions adopted in the current framework as a compromise between objective content definition, and definitions inspired by the studied approaches.

5

Acknowledgment This work has been funded in part by the Swedish Strategic Research Foundation under the research programs Artes and Save, and in part by the Royal Institute of Technology (KTH). The authors would like to express their gratitude to Paul Caspi, Tom Henzinger, Edward Lee, Ola Redell, Daniel Simon, Steve Vestal and Haiyang Zheng for their valuable feedback and suggestions.

6

References

[1] J. El-khoury, D. Chen and M. Törngren, A survey of modeling approaches for embedded computer control systems (Version 2.0). Technical report, ISRN/KTH/MMK/R-03/11-SE, TRITA-MMK 2003:36, ISSN 1400-1179, Department of Machine Design, KTH, 2003. [2] M. Törngren, and O. Redell, A Modeling framework to support the design and analysis of distributed real-time control systems, Journal of Microprocessors and Microsystems, Volume 24, No. 2, Elsevier, 2000. [3] L. Petersson, A framework for integration of processes in autonomous systems, PhD Thesis, ISBN 91-7283-251-7, Stockholm KTH, 2002. [4] R. Wieringa, A survey of structured and object-oriented software specification methods and techniques, ACM Computing Surveys (CSUR), Volume 30, Issue 4, Pages: 459 – 527, December, 1998. [5] N. Medvidovic, and R.N Taylor, A Classification and Comparison Framework for Software Architecture Description Languages. IEEE Transactions on Software Engineering, VOL. 26, NO. 1, JAN 2000. [6] P. C. Clements, A Survey of Architecture Description Languages, Eighth International Workshop on Software Specification and Design, Germany, March 1996. [7] D. Garlan, R. Monroe, and D. Wile, ACME: An Architecture Description Interchange Language, Proceedings of CASCON’97, November 1997. [8] T. Monroe, D. Garlan, D. Wile, Acme Language Reference Manual Version 0.1.1, http://www-2.cs.cmu.edu/~acme/ [9] T.A. Henzinger, B. Horowitz, and C.M. Kirsch, Giotto: A time-triggered language for embedded programming, In Proceedings of the First International Workshop on Embedded Software, LNCS 2211, pages 175–194. Springer, 2001. [10] T.A. Henzinger, B. Horowitz, and C.M. Kirsch, Embedded Control Systems Development with Giotto, Proceedings of LCTES 2001, ACM SIGPLAN Notices, June 2001.

179

[11] T.A. Henzinger, C.M. Kirsch, M.A.A. Sanvido, and W. Pree, From Control Models to Real-time Code Using Giotto, IEEE Control Systems Magazine 23(1):50-64, 2003. [12] N. Halbwachs. Synchronous programming of reactive systems: A tutorial and commented bibliography, Proceedings of CAV ' 98, LNCS 1427, pages 1--16, Vancouver, June/July 1998. Springer. [13] N. Halbwachs, P. Caspi, P. Raymond, and D. Pilaud. The synchronous data-flow programming language LUSTRE. Proceedings of the IEEE, 79:1305--1320, 1991. [14] P. Caspi, D. Pilaud, N. Halbwachs, and J. Plaice. LUSTRE: A declarative language for programming synchronous systems. In Proceedings of 14th ACM Conference on Principles of Programming Languages, pages 178--188. ACM Press, 1987. [15] P. Caspi, A. Girault, D. Pilaud, Distributing reactive systems, in Seventh International Conference on Parallel and Distributed Computing Systems, PDCS' 94, Las Vegas, USA, October 1994, ISCA. [16] N. Halbwachs, A Tutorial of LUSTRE, LUSTRE distribution, available by anonymous ftp from Imag. imag.fr as file /ftp/pub/lustre/tutorial.ps, Jan. 1993, 1-19. [17] P. Caspi, P. Raymond, From control system design to embedded code: the synchronous data-flow approach, Proceedings of the 40th IEEE Conference on Decision and Control, 2001 Pages: 3278 -3283 vol. 4. [18] P. Caspi, A. Curic, A. Maignan, C. Sofronis, S. Tripakis and P. Niebert, From simulink to SCADE/lustre to TTA: a layered approach for distributed embedded applications, Proceedings of the ACM SIGPLAN conference on Language, compiler, and tool for embedded systems, 2003, San Diego, California, USA, Pages: 153 - 162. [19] J. M. Drake, M. G. Harbour, J. J. Gutiérrez, and J. C. Palencia, Modeling and Analysis Suite for Real Time Applications (MAST 1.1), Description of the MAST Model, http://ctrpc17.ctr.unican.es/MAST. [20] J. L. Medina, J. M. Drake, M. G. Harbour, UML-MAST: Modeling and Analysis Methodology for Real-Time Systems Developed with UML CASE Tools, Proceedings of the Fourth International Forum on Design Languages, FDL’01, Lyon, France, September 2001. [21] M. G. Harbour, J. J. Gutiérrez, J. C. Palencia and J. M. D. Moyano, MAST: Modeling and Analysis Suit for Real-Time Applications, Proceedings of the Euromicro Conference on Real-Time Systems, Delft, The Netherlands, June 2001. [22] S. Vestal, MetaH User' s Manual, Version 1.27, Honeywell Technology Center, http://www.htc.honeywell.com/metah/uguide.pdf. [23] P. Binns, M. Englehart, M. Jackson, and S. Vestal, Domain-Specific Software Architectures for Guidance, Navigation and Control, IEEE Transactions on Software Engineering. Vol 20. 1994. [24] A. Agrawala, J. Krause, and S. Vestal, Domain-specific software architectures for intelligent guidance, navigation and control, IEEE Symposium on Computer-Aided Control System Design, (CACSD), Page(s): 110 -116, 1992. [25] S. Vestal, Integrating control and software views in a CACE/CASE toolset, IEEE/IFAC Joint Symposium on the Computer-Aided Control System Design, 1994, Page(s): 353 -358. 180

[26] S. Vestal, P. Binns, Scheduling and communication in MetaH, Proceedings of the Real-Time Systems Symposium, 1993, Page(s): 194 -200. [27] J. W. Krueger, S. Vestal, B. Lewis, Fitting the pieces together: system/software analysis and code integration using MetaH, Proceedings of the 17th Digital Avionics Systems Conference, Volume 1, 1998, Pages: C33/1 -C33/8. [28] P. H. Feiler, B. Lewis, S. Vestal, Improving Predictability in Embedded Real-Time Systems, Special Report, Software Engineering Institute, Report number: CMU/SEI2000-SR-011, December 2000. [29] D. Simon, B. Espiau, E. Castillo, K. Kapellos, Computer-aided Design of a Generic Robot Controller Handling Reactivity and Real-time Control Issues, IEEE Trans. on Control Systems Technology, vol. 1, no 4, December 1993. [30] D. Simon, B. Espiau, E. Castillo, K. Kapellos, Computer-aided Design of a Generic Robot Controller Handling Reactivity and Real-time Control Issues, Inria Research Report, no 1801, November 1992. [31] D. Simon, R. Pissard-Gibollet, K. Kapellos and B. Espiau, Synchronous composition of discretized control actions: design, verification and implementation with Orccad, 6th Int. Conf. on Real-Time Control Systems and Application, Hong Kong, december 1999. [32] D. Simon and A. Girault, Synchronous programming of automatic control applications using Orccad and Esterel, IEEE Conference on Decision and Control, CDC' 01, Orlando, USA, December 2001. [33] D. Simon, B. Espiau, K. Kapellos, R. Pissard-Gibollet, Orccad: Software Engineering for Real-time Robotics, A Technical Insight, Robotica, Special issues on Languages and Software in Robotics, vol 15, no 1, pp 111-116, March 1997. [34] X. Liu, J. Liu, J. Eker, and E. A. Lee, Heterogeneous Modeling and Design of Control Systems, Software-Enabled Control: Information Technology for Dynamical Systems, Tariq Samad and Gary Balas (eds.), Wiley-IEEE Press, April 2003 [35] E. A. Lee, Overview of the Ptolemy Project, Technical Memorandum UCB/ERL M01/11, University of California, Berkeley, March 6, 2001. [36] J. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt, Ptolemy: A Framework for Simulating and Prototyping Heterogeneous Systems,'Int. Journal of Computer Simulation, special issue on `Simulation Software Development,'vol. 4, pp. 155-182, April, 1994. [37] P. Whitaker, The Simulation of Synchronous Reactive Systems In Ptolemy II, MASTer' s Report, Memorandum UCB/ERL M01/20, Electronics Research Laboratory, University of California, Berkeley, May 2001. [38] W.-T. Chang, S.-H. Ha, and E. A. Lee, Heterogeneous Simulation -- Mixing Discrete-Event Models with Dataflow, invited paper, Journal on VLSI Signal Processing, Vol. 13, No. 1, January 1997. [39] J. Eker, C. Fong, J. W. Janneck, and J. Liu, Design and Simulation of Heterogeneous Control Systems using Ptolemy II, IFAC Conference on New Technologies for Computer Control (NTCC' 01), Hong Kong, China, November 2001.

181

[40] D. C. Luckham, J. Vera, and S. Meldal. “Three Concepts of System Architecture.” Technical Report, CSL-TR-95-674, Stanford University, Palo Alto, July 1995. [41] D. C. Luckham and J. Vera. “An Event-Based Architecture Definition Language.” IEEE Transactions on Software Engineering, pages 717-734, September 1995. [42] The Rapide Language Reference Manuals, http://pavg.stanford.edu/rapide/ [43] R. Bræk, SDL Basics, Computer Networks and ISDN Systems, volume 28, issue 12, p. 1585-1602, special Issue: SDL and MSC, June 1996. [44] R. Reed, SDL-2000 new presentation, http://www.sdl-forum.org/sdl2000present /index.htm. [45] Telelogic, Specification and Description Language (SDL), Web ProForum Tutorials, the International Engineering Consortium, http://www.iec.org/online/tutorials/sdl/index.html. [46] E. Holz, SDL-2000 Tutorial, Formal Methods Europa, FME 2001, Berlin, Germany, March 2001. [47] R. Reed, Notes on SDL-2000 for the new millennium, Computer Networks, volume 35, issue 6, p. 709-720, special issue: MSC and SDL in project life cycles, May 2001. [48] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Zelesnik. “Abstractions for Software Architecture and Tools to Support Them.” IEEE Transactions on Software Engineering, pages 314-335, April 1995. [49] G. Zelesnik, The Unicon Language http://www2.cs.cmu.edu/afs/cs/ project/vit/www/Unicon/.

Reference

Manual,

[50] T. Demmeler, B. O’Rourke, P. Giusto, Enabling Rapid Design Exploration through Virtual Integration and Simulation of Fault Tolerant Automotive Application, Society of automotive engineers, Document Number: 2002-01-0563, 2002. [51] T. Demmeler, P. Giusto, A Universal Communication Model for an Automotive System Integration Platform, Proceedings of the DATE 2001 on Design, automation and test in Europe, Munich, Germany, 2001. [52] R. J. Allen, A Formal Approach to Software Architecture, Ph.D. Thesis, Carnegie Mellon University, Technical Report Number: CMU-CS-97-144, May, 1997. [53] J. Ivers, Wright Analysis Tutorial, 2.cs.cmu.edu/afs/cs/project/able/www /wright/wright_tools.html

http://www-

[54] M. S. Jaffe, N. G. Leveson, Completeness, robustness, and safety in real-time software requirements specification, International Conference on Software Engineering, Pittsburgh, PA. May 1989, IEEE Computer Society. [55] M. S. Jaffe, N. G. Leveson, M. P. E. Heimdahl, and B. E. Melhart, Software requirements analysis for real-time process control systems, IEEE Transactions on Software Engineering, March 1991. [56] J. Rushby, Formal Methods and the Certification of Critical Systems, Technical Report, Number SRI-CSL-93-7. Computer Science Laboratory, SRI International, Menlo Park, CA. December, 1993.

182

[57] J. Rushby, Formal Methods and their Role in the Certification of Critical Systems, Technical Report, Number SRI-CSL-95-1. Computer Science Laboratory, SRI International, Menlo Park, CA. March, 1995. [58] R. Bishop, M.M Lehman, (1991), A view of software quality, IEE Colloquium on Designing Quality into Software Based Systems, 1991. [59] N. G. Leveson, Intent Specifications: An Approach to Building Human-Centered Specifications, IEEE Transactions on Software Engineering, VOL. 26, NO. 1, JAN 2000. [60] E. Rechtin, M. W. Maier, The Art of System Architecting, ISBN 0-8439-7836-2, CRC Press, 1997. [61] P.B. Kruchten, The 4+1 View Model of architecture, IEEE Software, Vol. 12, Issue: 6, Pages: 42–50, Nov. 1995, ISSN: 0740-7459. [62] L. Bass, P. Clements, and R. Kazaman, Software Architecture in Practice, ADDISON-WESLEY, ISBN 0-201-19930-3, 1998. [63] B. Blanchard, and W. Fabrycky, Systems Engineering and Analysis. Prentice-Hall, Englewood Cliffs, NJ. 1990. [64] P. Checkland, Systems thinking, Systems practice: Includes a 30-Year Retrospective. John Wiley & Sons. 1999. [69] N. Storey, Safety-Critical Computer Systems, Addison-Wesley, ISBN 0-20142787-7, 1996. [70] N. G. Leveson, Safeware – System Safety and Computers, Addison-Wesley Publishing Company, 1995, ISBN 0-201-11972-2.

183

184