Designing Heterogeneous Component Based. Systems: Evaluation of MARTE Standard and. Enhancement Proposal. Ali Koudri1, Arnaud Cuccuru2, Sebastien ...
Designing Heterogeneous Component Based Systems: Evaluation of MARTE Standard and Enhancement Proposal Ali Koudri1 , Arnaud Cuccuru2 , Sebastien Gerard2 , and Fran¸cois Terrier2 1
Thales Research and Technology 2 CEA
Abstract. Building complex real-time embedded systems requires assembly of heterogeneous components, possibly using various computation and communication models. A great challenge is to be able to design such systems using models where these heterogeneity characteristics are described precisely to assist the next step of the development including implementation or analysis. Although the new MARTE standard provides the core concepts to model real-time components using various communication paradigms, we state in this paper that MARTE extensions have still to be made and we propose to extract common features from several component based approaches in order to support finer compositions of heterogeneous sub-systems.
1
Introduction
Building real-time embedded systems through composition of well-defined and well-documented components is a tricky issue. Composition provides means to deal with complexity applying the “divide to conquer” paradigm. In the field of software engineering, composition issues are addressed by the Component Based Development (CBD) domain. Historically, CBD comes from disciplines of mechanical and electrical engineering where components are intuitively understood. In the field of real-time embedded systems (RTES), composition is difficult to achieve as complexity is increased by sub-systems heterogeneity (analog / digital devices, Globally Asynchronous Locally Synchronous systems – GALS, etc.) and real-time or other QoS issues. Then, a solid alternative is to consider UML models to handle such heterogeneity in a unified way. Unfortunately, current modeling languages lack means to specify rich interfacing and connections between components in both software and hardware domains. In this paper, we are interested in the “Interface Based Programming” applied to Model Based Engineering (MBE). In particular, we study how assembly can be achieved (interfacing conditions and constraints) and realized (allocation / implementation). We propose then to refine the notions of port, interface and connector of the MARTE GCM (Generic Component Model) sub-profile in order to achieve better composition and substitution capabilities in the context of heterogeneous real-time embedded systems design and analysis. J. Whittle, T. Clark, and T. K¨ uhne (Eds.): MODELS 2011, LNCS 6981, pp. 243–257, 2011. c Springer-Verlag Berlin Heidelberg 2011
244
A. Koudri et al.
In the next section, we provide a short survey on component-based approaches from several communities in order to extract key features component models should provide. Then, we list identified issues related to composition in UML, SysML and MARTE. In the third section, we propose a generic solution for composing heterogeneous system models. In conclusion, we provide insights on our future work.
2
Background
In software engineering, a component is defined as “a piece of self-contained, selfdeployable computer code with well-defined functionality that can be assembled with other components through its interface” [14]. More precisely, a component model defines “rules for the specification of component properties and mechanisms for component composition, including composition rules of component properties”. This definition distinguishes three important parts: the specification of components internals, including functional and non-functional properties; the specification of components interfaces, e.g. what they provide/require to/from their environment; the specification of interactions. While the first and the second parts are usually well addressed by architectural patterns, the third part is usually not explicitly specified and is related to implicit communication patterns. In order to provide a better understanding of composition, authors of [2] present a framework for software components that compares interfacing and interaction styles. According to this survey, an interface is mainly characterized by: its type, e.g. operation-based (service invocations) or port-based (data-flow); the distinction between its provided/required parts; the existence of distinctive features (optional modes); its specification language; its contractualisation level (syntactic / semantic / behavioral). Besides, authors characterize interactions by: their interaction type (e.g. request/response, message passing or event-driven); their communication type (e.g. synchronous or asynchronous); their binding type (e.g. connection, hierarchy or both). In hardware engineering, evolution of technologies has pushed the usage of hardware components as well. Indeed, design of Integrated Circuits (IC) or Very Large Scale Integrated Circuits (VLSI) requires techniques to handle exponential complexity due to Moore’s law. Then, hardware engineers can achieve a better productivity assembling reusable and reliable blocks (Intellectual Properties – IP): microprocessor, DSP, memory, bus, etc. Indeed, component-based approaches have been long used with success in hardware engineering and have proven their relevancy to handle complexity and productivity. Unfortunately, the aforementioned approaches are mainly focused on implementation issues and higher level approaches are required to favor analysis activities. To this end, several Architecture Description Languages (ADL) have been proposed in both software and hardware domains. According to [9], the purpose of an ADL is to shift from lines-of-code to coarser-grained architectural elements (components and connectors). Then, authors define an Architecture Description Language as “a language that provides features for modeling a software system’s
Designing Heterogeneous Component Based Systems
245
conceptual architecture distinguished from the system’s implementation.” Still, there is no consensus on what aspects of architecture should be modeled and interchanged. For instance, among all existing ADLs, some of them are just used to provide a better understanding of the system (global behavior and communications) while other provide full featured language along with analysis tools, checkers, compilers, synthesis tools, etc. Whatever, an ADL should provide at least a simple and understandable syntax, possibly graphical, to improve the system analysis. This syntax must rely on a clear semantics avoiding ambiguities. In [13], authors elaborate six classes of properties all ADLs should provide: composition, abstraction, reusability, configuration, heterogeneity and analysis. In particular, they argue the need to consider the connector as a first-class entity to support heterogeneity. In [9], authors provide a comparison framework for ADLs. In this framework, both component and connector are characterized by their: Interfaces, defining a set of interaction points providing/requiring services (messages, operations, variables) to/from external world – Services are related to computations in the case of components and to communications in the case of connectors; Types, defining a configurable abstraction allowing re-usability, and extensibility – Modeling connectors as type makes sense because interactions are often characterized by complex protocols; Semantics, representing a high level behavioral model which is required to perform analysis or to ensure consistent mappings from one level of abstraction to another; Constraints, defining assertions whose violation would render the system unacceptable; Non-functional properties, e.g. properties that cannot be derived directly from the specification of behaviors (safety, security, performance, etc.). Such properties are required early in the design process to perform relevant analysis or to foster replaceability in context.
3
Motivations
The specification of UML 2.0 [10] introduces several important concepts for supporting composition: Collaboration, Port, Connector, etc. Unfortunately, the semantics of those elements is generally not well defined. The main reason of this lack is because such semantics depends on target domains. Indeed, it is suggested in p.147 of the specification that “profiles based around components will be developed for specific component technologies”. In SysML [11], components have been introduced under the notion of “Block” which is defined as “a modular unit of system description” providing general purpose capabilities to model large and heterogeneous systems. SysML refines the UML components in different ways: reusable constraints, multi-level nesting of connector ends, etc. In MARTE [12], the Generic Component Model (GCM) sub-profile provides the core concepts to model real-time and embedded system components. Those concepts represent a common denominator among various component models (lightweight-CCM, AADL, EAST-ADL2, etc.) except that no specific execution semantics has been tied. For instance, a structured component is defined as “a self-contained entity of a system which may encapsulate structured data and behaviors”.
246
A. Koudri et al.
Regarding UML components, several issues have been raised by the OMG and show inconsistencies in both syntax and semantics: – Handling of requests by ports (behavioral or not) is not clear (issue 10597), – Typing a port by a class, behavioral or not, has not a clear semantics (issue 15290), – Connectors do not provide means for specifying an interaction pattern between involved roles played at connector ends (issue 10474). Even if SysML proposes refinements of ports, interfaces and connectors, there are still several lacks and semantics issues that have been raised: – In some situations, it would be useful to be able to attach a protocol state machine to ports (issue 10047), – Handling of complex ports, mixing services and data-flows, is not well addressed (issues 10059 and 12269), – Nothing is said about the semantics of binding connector ends with different multiplicities (issue 11333), and particularly in the context of continuous flows (issue 15298), – Binding connectors should be typed in order to support decomposition (issue 15079), – There are limitations to represent certain kinds of interfaces (mechanical, electrical, etc.) and ports. For instance, issues 12156 and 15076, propose to introduce the notions of “Junction Port” and “Non-flow property Port”. Issue 13179 adds that, in this context, an integration of Modelica concepts should be discussed, – Issue 13178 suggests that a flow specification should not be a refinement of an interface because port decomposition in that case would not be possible. Since MARTE reuse definitions of SysML blocks, interfaces and connectors, issues presented above are also applicable in this language. To give insights to those questions, we use the study from section 2 to abstract common denominators so we can propose a flexible way to specify components and composition that takes into account systems heterogeneity. This work is required in order to foster the use of models for design, analysis and implementation of RTES.
4
Contribution
Ideally, the MBE combined with CBD provides a powerful approach as it facilitates design and analysis activities though a clear separation of concerns. In practice, this is another story; and before such approach comes to reality, we have to make efforts to finely characterize components, their interfaces and connectors. To this purpose, we propose to extend the component model of the MARTE GCM sub-profile to tackle issues presented in section 3. This work aims to improve analysis as it contributes to handle emergent behaviors related to implicit choices.
Designing Heterogeneous Component Based Systems
4.1
247
Core Principles
Today, design methodologies and environments integrating semantically distinct models are in high demand [4]. From study of section 2, we can state that, at some level, hardware and software developments are quite similar: engineers have to think in terms of data, computation, communication and architecture. Then, a system should be conceived as an understandable architecture of cooperating agents which characteristics and interactions should be well understood under a certain Model of Computation (MoC). For instance, the rugby conceptual model [7] states that from specification to implementation, the complexity of a system can be managed through several representations mainly characterized by four axes: Computation represents relationship between the inputs and the output of the system: it can be captured for example by an Ordinary Differential Equation at high level or a Netlist at low level; Communication represents means for structural elements to exchange data: it can be a functional call at high level or a complex bus at low level; Data represents information produced or consumed by structural elements: it can be abstract data types at high level or bit vectors at low level; Time represents the causality of the system: it can be causal at high level (succession of events) or clocked at low-level. Modeling and analysis of complex systems, composing heterogeneous parts, requires taking into account each of those properties. In particular, we need to understand in what circumstances interactions between such heterogeneous parts can occur. According to [6], modeling explicitly MoCs characteristics has several advantages: Faster specification development through usage of appropriate primitives and rules; Optimum simulation speed using a unified simulation engine instead of using multiple languages / frameworks; Useful properties: determinism, protection against deadlocks, introduction of non-determinism only when needed; Feasible implementation flow through usage of a syntax which is semantically identifiable by compilation / synthesis tools. Besides, in [5], authors identify two kinds of specification / integration of MoCs. The first one, called horizontal heterogeneity, refers to the ability to integrate a component among others on the same level of abstraction. The second one, called vertical heterogeneity, is mainly related to refinements of components between several levels of abstraction and requires transformations. The next section presents the main concept of our extension to address modeling of heterogeneity for RTES design and analysis. 4.2
Main Concepts
Complex ports. In order to tackle issues related to ports presented in the previous section, we introduce the notion of “complex port” in the GCM MARTE sub-profile. This notion refines the UML port in order to support structural decomposition as well as behavioral specification. A complex port conforms to a “port specification” which defines its structural and behavioral features (figure 1). Its usage serves several purposes.
248
A. Koudri et al.
! "
#$
Fig. 1. Refinement of MARTE GCM Port Definition
!" #$ % & #$ %& #$ %
#$ % #$ %
Fig. 2. Ports Group definition
First of all, building large hierarchical systems often requires gathering ports into groups to favor readability and reusability. For instance, figure 2 shows a simple concrete example of complex port usage extracted from OCP/IP specification [1]. We can see in this figure how a complex port can be used to gather a set of ports into a reusable element. We can also notice that such representation improves the readability of the models. Regarding the issues presented above, this first example shows how our proposition contributes to tackle issue 13178. Another benefit of this proposition is to be able to explicit the way requests / flows must be handled. Indeed, a port specification can contain definition of specific data structures and behaviors required to implement a protocol (using protocol state machines for example) in case of client / server ports, or to specify how received data are transformed in case of flow ports. Then, the property “isLightweight” indicates whether the port has to perform some computation on received data / requests. Setting this property to “false” implies for the port: the specification of discrete or continuous behavior; the specification of both external / internal interfaces, e.g. what is provided / required to / from respectively the context and the nested elements of the component. External and internal interfaces of a port represent two subsets of its nested ports. The first one (external interface) contains ports that are externally visible features (isService=true), while the second one are only internally visible features (isService=false).
Designing Heterogeneous Component Based Systems
249
Fig. 3. Specifying junction ports
The figure 3 shows a simple concrete example from a “Software Defined Radio” application where there is a need to specify that incoming signals are mixed before being processed by the signal processing chain. The ports specification of this figure defines actually a junction port where signals mixing occur. In software domain, one could use for example port specification to store arrival requests (possibly with a timeout) until they are consumed by nested behavior(s). We can see that, in this case, our proposition contributes to give an answer to issues 10597, 15290, 10047, 12156, 13179 and 15076. Additionally, complex ports decomposition allows mixing both services and data-flows ports in an explicit way, which contributes to give an answer to issues 10059 and 12269. Finally, our proposition addresses also the routing issue, e.g. how a request / flow is propagated to /from the component in case of multiple choices? UML is not clear on that point. We think that such decision is domain dependant and should be explicitly captured in the model. The Routing Policy defined by the port tells whether to propagate the request to the first connector (routing=first ), to any of those connector (routing=any) or to all connectors (routing=all ). For a finer routing decision, one can use a complex connector defining a path between internal and external interfaces. Complex connectors. Introducing complex ports requires dedicated mechanisms to take into account hierarchy of complex ports. To this purpose, and to clarify inter-connections in UML, we introduce the notion of complex connector. The figure 4 shows the abstract syntax of complex connector which extends the UML connector in order to reinforce its semantic and to provide syntactic facilities to express multi-level nested connections. In order to better explain introduced concepts, we distinguish three cases in the following paragraphs: the first one clarifies connections in UML; the second one deals with inter-connections of complex ports; the last one discusses usage of typed complex connectors.
250
A. Koudri et al.
" $
" $
" $ #
" #$ %
*
)
& " $
)
" $
" #$ %
!
" #$
" $
& &
' &
" $
( & ' &
%
Fig. 4. Refinement of MARTE GCM Connector Definition
To illustrate the first item, we will use an image processing application as example. We consider a piece of the Lucas-Kanade algorithm dedicated to tracking [8] presented in figure 5.
Fig. 5. Tracking System Data-Flow
In this figure, we can see that the algorithm takes as input a set of eleven images which are distributed among 5 Gaussian Smoothing blocks. The resulting images are then passed to 3 different blocks that perform spatial and temporal gradients to produce new images.
Designing Heterogeneous Component Based Systems
251
!"
#
$
Fig. 6. Tracking System Model
To model this algorithm using UML composite structure and flow ports, we would produce the diagram presented in figure 6. This diagram makes benefits of syntactic facilities of UML to produce a concise model. Unfortunately, because interpretation of cardinalities of both parts and ports between connected elements is not clear in UML, it is quite impossible to infer the architecture presented in figure 5 from the model of the figure 6.
!
"
!
#
"
$ # $
&
!
'
"
# $
#
%
Fig. 7. On richer connection specification
252
A. Koudri et al.
The figure 7 illustrates how our proposition addresses this problem. In the left side of the figure, we can see how the delegation connector set between the input port of the tracking system and the “gs” part should be interpreted. Such interpretation could be achieved in UML at the price of big efforts using OCL constraints. In the right side of the figure, we can see the corresponding repository view. A connector owns several connector ends which store relevant information on richer connection specification. More precisely, a connector owns several connector ends that precise finely how related elements are connected. In this example, we can see that each connector end selects specific parts and roles from respectively their partWithPort and role properties using value specification. In this case, we have just used an index to select which parts and roles are involved into the connection, but it could be any other discriminating factor (the best QoS for example). This simple example can also be applied to assembly connector as well as connectors related to service ports. This example shows how our proposition contributes to give an answer to issues 11333 and 15298. To illustrate the second item, e.g. connection between complex ports, we use the example of the figure 8 which shows a connection between an abstraction of an ARM9 processor and an OCP-IP bus, both complying with OCP-IP standard specification [1]. In this example, we aim to express connections between nested ports defined by ports specification. Using UML, we can connect only the first level of the port hierarchy. Thanks to our extension, it is possible to precise which “sub-ports”
%
%
%
%
!" #$
!" #$
&
%%
%
%
Fig. 8. Connecting Complex Ports
!" #$
Designing Heterogeneous Component Based Systems
253
are connected to each other. The upper part of this figure shows the connection between two complex ports of the two parts of the hardware design. Using UML connectors cannot fit the need to specify how the connector is refined through port decomposition. Then, the middle part of the figure shows in more details how a complex connector can be used to achieve such refinement. For instance, we show in this figure that the connector contains two initial ends connecting the first level of the ports hierarchy. The connector owns other connector ends that define a path from initial ends. In this example, we can see that each initial end posses a reference (next end ) to another connector end. Connector ends that are leaf reference one or several opposite ends from which we can infer the refinement of the connector as shown in the lower part of the figure.
Fig. 9. Repository view
The model repository view presented in figure 9 shows that our proposition clarifies the specification of interconnections between nested ports. This figure focuses on interconnections between sub-ports “sres” of the figure 8. Compared to the RSM sub-profile of MARTE which allows only specification of regular patterns [3] in complex connections, our proposition is complementary as it allows specification of irregular patterns as well. We see through this small example how our proposition contributes to give a partial answer to issues 10474 and 15079. Regarding the last case, connectors must provide more detailed information to precise finely how messages are conveyed between ports. According to the UML specification, a connector can be realized by a simple pointer as well as a complex network. In the latter case, a connector can be seen as a black box into which several kinds of operation can occur: dispatching, filtering, data corruption, data transformation, etc. Then, in order to achieve realistic analysis, we must be able to specify such features for any complex connector. A UML connector can only be typed by an association, which represents a great limitation to model any behavioral feature required to model and analyze complex
254
A. Koudri et al.
communications. That is why we have introduced the notion of connector specification to type connectors. A connector specification gathers a set of common features a family of connectors share. For example, the connector between the “Smoothing3” block and the three “Gradient” blocks of the figure 5 illustrates such complex connector. In this example, each image produced by the “Smoothing” block is sent to “X-Gradient” and “Y-Gradient” blocks. Produced images are then queued because the “T-Gradient” block requires 5 images to perform a computation. This kind of model corresponds actually to the Synchronous Data Flow MoC where production and consumption rates are well-known. As we cannot specify such connector using an UML association, the figure 10 shows how our proposition handles this issue.
! "#$
Fig. 10. On richer connection specification
In this example, the specification of the connector is given by the “CS” class which defines one fifo to store incoming images and two behaviors triggered when new images are ready to be processed. The first behavior copies the incoming image into the fifo and the second one sends a block of five images to the “TGradient” block when the fifo is full. Interface realization and usage. We have seen in section 3 that Interface Based Programming is the support of the replaceability in context. An interface defines common features a set of components should provide to be used indifferently. This suggests that there exists somehow a matching between the features an interface exposes and the visible features of the implementing component. In current approaches, such matching is implicit and consists usually in name matching. We have seen in section 2 that, among existing CBD approaches, there are several level of conformance between an interface and its implementations (syntactic, structural or behavioral). In this paper, we distinguish between three incremental levels of conformity: Structural conformity: a
Designing Heterogeneous Component Based Systems
255
component is replaceable if it has compatible properties; Behavioral conformity: a component is replaceable if it has compatible properties and behaviors (example: protocol); Non-functional conformity: a component is replaceable if it has compatible properties and behaviors, and it provides the same non-functional properties (example: latency). Using UML, one can specify that a classifier realizes an interface using the Interface Realization direct relationship. This relationship references the contract and the implementing classifier. Thus, the metamodel assumes only a syntactic conformance since no additional information is given about the level of conformance and the way the implementing classifier implements / uses effectively a contract. In RTES, this situation is not acceptable as RTES requires more than a syntactic conformity to allow replacement of a component by one another. We propose then to refine both interface realization and usage.
!"! #!$ ! !"!%&#! '&!
!"!! / ( )
( )
-.)
!"! )
!"! &! ( ) &
!"! &! !"! 0 &&! 1/ !"! ) &!
!"!! /
!"! #!$ ! !"!%&#! '&!
!"! &!
!"! )
) '& )) * +, ()
2) 3
Fig. 11. Refinement of MARTE GCM Interface Definition
Figure 11 presents the abstract syntax of our proposition which is illustrated through the example of the figure 12 taken from the Lucas-Kanade algorithm mentioned above. The left side of the figure 12 tells that the “IMultiplier” block conforms to the “IMultIface” interface, although the signatures of its properties are not the same either in name or in cardinality. In this case, syntactic conformance does not work. Then, we need additional information in the interface realization link to specify how the implementing block actually realizes its interface. We need to express a fine mapping between the properties of the interfaces
256
A. Koudri et al.
and the ones of the block. The right side of the figure shows the model repository view focusing on the feature mapping between property “img1” of the interface and the port “itxy[0]” of the block.
!
"
!
"
Fig. 12. Example of interface realization
Besides, finer mappings can be expressed using a mapping expression in the feature mapping. For instance, one could split a single property into two distinct properties. For example, we could imagine an unsigned integer property coded into 32 bits (uint < 32 >) mapped into two unsigned integer ports coded into 16 bits (uint < 16 >) for both Most Significant Bits (MSB) and Least Significant Bits (LSB) parts of the property. We see through this simple example that our proposition contributes to clarify interfaces usage and realization. Moreover, such specification can be used to automate generation of wrappers or complex connectors facilitating COTS IP integration.
5
Conclusion
Component Oriented Modeling offers several advantages: It is an interface-based approach providing loosely-coupled specifications and favoring better reuse; It provides high level services for NFP (Non-Functional Properties) support; It provides a better support of allocation. Actually, those assumptions are true only if the semantics of components and composition of heterogeneous systems are clearly and unambiguously defined. In this paper, we have presented a small survey on component based approaches from several domains. From this survey, we have extracted common denominators in order to propose a generic approach that encompasses design and analysis of heterogeneous real-time systems. This proposition aims to give a practical answer to issues raised by the OMG and contributes to reinforce the semantics of real-time components and composition in the UML for MARTE profile.
Designing Heterogeneous Component Based Systems
257
Beyond UML for MARTE, this work can be generalized to the component model of UML. This work contributes also to explicit the various models of computation and communication of real-time embedded systems. It allows the establishment of libraries of reusable and configurable ports and connectors. Future works will have to take into account system validation through vertical refinements of components as well as support of behavioral and non-functional conformity in order to enable component replaceability in context. This work is partially founded by the VERDE project (http://www.itea-verde.org/).
References 1. Open core protocol specification 2. Crnkovic, I., Chaudron, M., Sentilles, S., Vulgarakis, A.: A classification framework for component models. In: Proceedings of the 7th Conference on Software Engineering and Practice in Sweden (October 2007) 3. Cuccuru, A., Dekeyser, J.-L., Marquet, P., Boulet, P.: Towards UML 2 extensions for compact modeling of regular complex topologies. In: Briand, L.C., Williams, C. (eds.) MoDELS 2005. LNCS, vol. 3713, pp. 445–459. Springer, Heidelberg (2005) 4. Eker, J., Janneck, J., Lee, E.A., Liu, J., Liu, X., Ludvig, J., Sachs, S., Xiong, Y.: Taming heterogeneity - the ptolemy approach. Proceedings of the IEEE 91(1), 127–144 (2003), http://chess.eecs.berkeley.edu/pubs/488.html 5. Herrera, F., Villar, E.: A framework for heterogeneous specification and design of electronic embedded systems in systemc. ACM Trans. Des. Autom. Electron. Syst. 12(3), 1–31 (2007) 6. Jantsch, A.: Modeling Embedded Systems and SoCs. Morgan Kaufmann, San Francisco (2004) 7. Jantsch, A., Kumar, S., Hemani, A.: A metamodel for studying concepts in electronic system design. IEEE Des. Test 17(3), 78–85 (2000) 8. Mahalingam, V., Bhattacharya, K., Ranganathan, N., Chakravarthula, H., Murphy, R.R., Pratt, K.S.: A vlsi architecture and algorithm for lucas-kanade-based optical flow computation. IEEE Trans. Very Large Scale Integr. Syst. 18(1), 29–38 (2010) 9. Medvidovic, N., Taylor, R.N.: A classification and comparison framework for software architecture description languages. IEEE Trans. Softw. Eng. 26(1), 70–93 (2000) 10. OMG: Omg unified modeling languagetm (omg uml) superstructure (v2.3). Tech. rep., OMG (2010) 11. OMG: Sysml 1.1. Tech. rep., OMG (2010) 12. OMG: Uml for marte 1.0. Tech. rep., OMG (2010) 13. Shaw, M., Garlan, D.: Characteristics of higher-level languages for software architecture. Tech. rep., Carnegie Mellon Univ. (1994) 14. Wang, A.J.A., Qian, K.: Component-Oriented Programming. Wiley, Chichester (2005)
