modeling and analyzis of real-time and embedded systems
TRANSCRIPT
Modeling and Analyzisof Real-Time and Embedded Systems
with the MARTE UML profile
DATE2008 Friday Workshop - 14th March, 2008
Room 12b
2
ContentsMARTE usages in the industry 5
1.1 Holistic System Modeling and Refinement of Interconnected Microelectronic Systems, JochenZimmermann, Oliver Bringmann, Joachim Gerlach, Florian Schaefer and Ulrich Nageldinger . . . 5
1.2 Using MARTE in a Co-Design Methodology, Ali Koudri, Denis Aulagnier, Didier Vojtisek, PhilippeSoulard, Christophe Moy, Joël Champeau, Jorgiano Vidal and Jean-Christophe Le Lann . . . . . . 11
1.3 Evaluating MARTE in an Industry-Driven Environment: TIMMO’s Challenges for AUTOSARTiming Modeling, Huascar Espinoza, Kai Richter and Sébastien Gérard . . . . . . . . . . . . . . . 17
MARTE in the Embedded System Design Toolbox 232.4 Gaspard2: from MARTE to SystemC Simulation, Éric Piel, Rabie Ben Attitalah, Philippe Marquet,
Samy Meftali, Smaïl Niar, Anne Etien, Jean-Luc Dekeyser and Pierre Boulet . . . . . . . . . . . 232.5 Executable models and Verification from MARTE and SysML: a comparative study of code genera-
tion capabilities, Marcello Mura, Amrit Panda and Mauro Prevostini . . . . . . . . . . . . . . . . 292.6 Modeling SPIRIT IP-XACT with UML MARTE, Charles André, Frédéric Mallet, Aamir Mehmood
Khan and Robert de Simone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.7 Tool Support for a Scheduling Analysis View, Matthias Hagner and Michaela Huhn . . . . . . . . 41
3
4
Holistic System Modeling and Refinement ofInterconnected Microelectronic Systems
Jochen ZimmermannOliver Bringmann
FZI [email protected]@fzi.de
Joachim GerlachRobert Bosch GmbH
Florian SchaeferCadence Design [email protected]
Ulrich NageldingerInfineon Technologies AG
Abstract—In this paper, we propose an approach for modelingdistributed embedded systems in a holistic way starting from anabstract specification of system requirements. We use the UnifiedModeling Language (UML), which is very popular in softwaremodeling and development, for describing both the target plat-form and the functionality, which has to be performed on thattarget platform, at a high abstraction level - even at system level.Therefore, we extended the existing UML profile MARTE tomeet the requirements of distributed systems. These extensionsenable to associate the elements of the model semantically andhence to use UML as a common underlying data model forsystem representation. Based on the holistic modeling approachan executable simulation model is generated in SystemC tofacilitate exploration and verification of system behavior.
I. INTRODUCTION
In recent years it has turned out that the driving forcesfor new end-user applications are interactivity, mobility andindividual need for safety, security, comfort and health in ahighly interconnected world.
The applications rely on interconnected individual process-ing power combined with the networking of all informationand communication technologies. Examples are not restrictedto communication systems. For example, modern vehiclescontain a network of interconnected electronic control units(ECUs) communicating via different busses using severalprotocols (e.g. CAN, MOST, FlexRay), and tomorrow’s auto-motive networks will have to support highly safety-critical andreliable systems, like X-by-wire. Current and future mobilephones resemble heterogeneous system conglomerates of bothchip components, which may again contain complex subsys-tems (e.g. baseband, RF, application processor, memory) andadvanced peripherals, like cameras or memory card interfaces,communicating over a number of both on-chip and off-chipinterconnects (e.g. I2C, I2S, I2RF). Thus, microelectronicsystems migrate towards highly interconnected “systems ofsystems” resulting in a growing degree of complexity andinteraction. An increasing number of subsystems are involvedin providing a specific system function, and more and moresystem functions are sharing a heterogeneous network ofdistributed resources. In this context, interaction becomes eventhe most critical challenge of the design process.
In future, new system functionalities will be built less byisolated components and more by interaction of components
within an interconnected system environment. Therefore, in-terconnection and networking will become the main driversfor innovation. The added value of a product will increasinglyresult from synergetic networking. As a consequence, the roleof suppliers will also change significantly: The responsibilityfor the overall system behavior and reliability will be more andmore devolved to the component supplier. In this new position,the supplier is responsible not only for individual componentdesign but also for the integration of the component into theembedding system.
Following today’s design strategies, components are spec-ified independently and integrated afterwards, environmentalrequirements are not considered sufficiently into the intercon-nected system model, and a seamless link to executable high-level system models is missing.
This also results in new challenges for microelectronicsystem design. As today’s design methodologies and tools aremostly oriented to design single components, they are hardlyable to support the design of interconnected and distributedsystem solutions with high demands on flexibility and relia-bility. Thus, the various dependencies of system networkingare considered insufficiently. As a consequence, future designsneed to be done in the context of their embedding hardwareand software system, and have to consider the communicationcharacteristics and requirements of their embedding environ-ment. This requires a paradigm shift in microelectronic systemdesign methods. To cope with that challenge we proposea holistic modeling approach for distributed microelectronicsystems based on the Unified Modeling Language (UML)which combines both hardware and software view in anintegrated system development process.
II. PLATFORM MODELING
Generally, in a platform-based design of an embeddedsystem [1] functional units, which realize the requested systembehavior, are mapped onto architectural components through asystematic process. Then, the resulting platform is optimizeduntil all necessary system requirements are met.
In the following, the modeling of both behavior and targetarchitecture in UML and the mapping of functional unitsonto platform components is described in details. In the
5
context of this modeling approach, target architecture meansthe underlying hardware platform.
A. Target Architecture Modeling
The Unified Modeling Language (UML) is commonly usedfor modeling software systems both in the specification andthe development process. Whereas in the microelectronicworld, UML is almost unknown because it’s considered tobe too complex and time-consuming. Moreover, the inside ofhardware blocks is usually not revealed to protect intellectualproperty (IP).
But as stated before, supplier of microelectronic systems aremore and more not only responsible for individual componentdesign but also for the integration of the component intothe embedding system. Therefore, many supplier provide acomponent specification in a standard IP-XACT format toenable an independent system integration.
In our approach, IP-XACT [2] serves as a basis for themodeling of the underlying hardware architecture. IP-XACTprovides a common specification mechanism for describingand handling intellectual property (IP), e.g. definitions of in-terfaces, ports, and address spaces. The component descriptionused to be mainly at RT level but since version 1.4, IP-XACT methodology has been accumulated with ESL exten-sions which include module hierarchy and multiple views ofdifferent levels for a component supporting mixed IP modelingabstraction levels.
Starting from standard component description of microelec-tronic processor and interconnection resources in IP-XACTthese components are integrated into existing and well-knownUML design environments. The result is a UML componentlibrary which can be used for structural modeling in variousUML diagrams. Therefore, we transform IP-XACT componentdescriptions via XMI to environment-specific UML com-ponents. This UML components encapsulate UML classesas attributes to represent component elements, e.g. addressspaces, registers, and ports. Furthermore, UML componentsand classes can hold operations which are specified throughan IP-XACT file set, e.g. C functions of an encoder.
By applying a domain-specific UML profile in the exportprocess the semantics of the modeling elements is defined.This forms a common modeling basis for a connection be-tween target architecture and behavior, and also betweenhardware and software development.
The UML profile MARTE [3], which currently resides inthe standardization process of the Object Management Group(OMG) [4], has been developed for modeling real-time andembedded systems. Nevertheless, it has turned out that theMARTE profile is not sufficient to model microelectronicsystems in a complete manner – especially not in the System-on-Chip (SoC) area.
So, we had to extend MARTE by a domain-specific UMLprofile which also allows the modeling of registers, protocols,and so on. We added appropriate stereotypes and tagged valuesto adapt the UML meta model to the SoC application area.
During the import process of IP-XACT component descrip-tions to the UML design environment the generated UMLclasses, which are going to be generated, are denoted bystereotypes. Specific recognition features are used to performa semantic classification, e.g. whether there are bus interfaces,or registers, or internal channels defined in the componentdescription. Finally, the assignment of stereotypes is done byregarding a pre-defined mapping table.
In a UML class diagram these generated classes are put intorelationship to each other, e.g. associations or generalizations,representing the internal structure of the modeled system.Since UML version 2.0 the coherence of complex systemarchitectures and especially the interconnection of systemcomponents are modeled in a component diagram, which canbe created using our generation approach.
Fig. 1. Component Diagram for High-Level Platform Modeling
Figure 1 depicts a multi processor platform which con-sists of two bus units from the AMBA family, two Leon2processors, a hardware RAM and an ASIC. The abstractionlevel of the representation depends on the view of the modeland is therefore implicitly defined by using a certain type ofUML diagrams. In a structural view, the component portsand their connection is basically relevant. For this reasona component diagram abstracts away all internal attributesand simply shows the components including their componentports and the dedicated communication network. Whereas in acomponent-centric view, the model is rather focused on com-ponent attributes, and tagged values respectively. Hence, thisdiagram type forms an interface to the behavioral modelingwhich is described in section II-C.
This UML platform model can also be encapsulated in acomponent to be available in further models as a parameteriz-able subsystem. This so-called blackbox approach of platformtemplates is very practical if subsystems are already verifiedor included in system design as intellectual property.
6
B. Architecture Refinement
To manage the complexity of today’s microelectronic de-signs, both the architecture and the communication of dis-tributed system elements have to be modeled at a high ab-straction level.
Fig. 2. Communication at High Abstraction Level
Figure 2 depicts a processor and a bus which are linkedtogether by a simple connection modeling a high-level com-munication. Details of this communication, e.g. types of ports,are abstracted away to allow to connect system componentswithout the need to deal with low level signals, appropriateinterfaces, protocols, and so on. Designer are enabled to modeldistributed systems fast and easily.
As a matter of course, these high-level models are not ac-curately enough when implementation of the modeled designis concerned. In an IP-XACT component, bus interfaces aregroups of ports that belong to an identified bus type, andrepresent the connection of the component to the outside.Group of ports that together perform a function are definedby the busDefinition and abstractionDefinition, which containsthe low-level attributes of an interface. A component businterface refers to a certain abstractionDefinition and thereforeindicates that the corresponding port implements the specifiedport function.
Fig. 3. Interface Specification using IP-XACT abstractionDefinitions
In figure 3, the interface concept of IP-XACT is mapped toUML interfaces. Port definitions of the abstractionDefinition,namely RW TRANSACTION, are transformed to UML classesand get associated with the specified component interfaces
which they refer to. As a consequence, component ports oftype RW TRANSACTION, which are represented as UMLports, can be provided with the appropriate interfaces.
Fig. 4. Refinement of High-Level Communication
With this approach, communication channels which aremodeled at a high abstraction level (cf. figure 2) are refinedto a lower abstraction level adding defined interfaces to themodel. In the component diagram these interfaces are linkedtogether representing component interconnection. The refinedcommunication interconnect is depicted in figure 4.
The target platform including communication refinement isdisplayed in figure 5.
C. Modeling of Behavior
To model functional behavior UML provides behavioraldiagrams like activity diagrams, sequence diagrams, and finalstate machines. The export process of IP-XACT componentdescription, which is described in section II-A, and thegeneration of UML component library in the UML designenvironment, enables system designers to work directly oninstances of these components. Component dependencies areimplicitly defined by using component representations in UMLclass diagrams.
As an example, operation rd mem() of a processor readssome data out of a memory and therefore implements a pro-tocol which consists of several protocol steps. This operationcan be modeled precisely using a sequence diagram whichembraces instances of CPU1, AHB, and RAM in figure 1.
Furthermore, state machines can directly refer to configura-tion registers, which are also defined in IP-XACT format. Withthese reference to configuration registers the control flow ofthe component or the system is modeled. Depending on currentregister values different component algorithms are triggered,e.g. filter algorithms to process a continuous data flow inmobile communication.
7
Fig. 5. Component Diagram for Platform Modeling with Interfaces
Another way to specify functional behavior are pure func-tion calls to existing source code, e.g. in C/C++ or VHDL.The methodology of behavior from source code is therebyindependent from being implemented in hardware or software.
Modeling of behavior depending on specified system com-ponent resources plays a key role in the generation processof virtual prototypes starting from an abstract UML systemmodel. This process is described in section IV.
III. SYSTEM MAPPING
By the use of UML as a common data model for both thetarget architecture and the functionality there exists a model-based relation between different views of system integration,e.g. hardware and software development. This facilitates thecomposition of components to a target platform at a highabstraction level.
Additionally, by applying further UML profiles to thesystem model, e.g. SysML [5], non-functional properties likeperformance, reliability, and timing behavior can be factored inthe model. Thus, an explicit interface from system modeling torequirements management and the verification of pre-definedrequirements occurs.
The junction of the different views mentioned above is alsoone part of the coherent modeling methodology based on UMLas underlying common data model. In this process, it hasto determined which functionality is mapped, and executedrespectively, on which available resource in the model. UMLprovides deployment diagrams to realize this mapping func-tion.
Fig. 6. General Mapping Process of Structural and Behavioral Diagrams
Figure 6 shows the mapping process of structural and behav-ioral diagrams in general. The modeling of the target platformhas already been described in section II-A. This target platformmodel is represented by XML code, which is automaticallygenerated by the UML design environment. Both hardwareand software functionality is encapsulated into UML artefacts
8
which are mapped onto structural elements in a deploymentdiagram. These structural elements, e.g. UML devices, repre-sent abstract system components. By this mapping process offunctionality, which is extracted from behavioral diagrams, ordirectly from source code, and represented by communicatingprocesses, an abstract system model is generated. In furthersteps, this abstract model can be transferred into an executablemodel which is used to perform the refinement of the entiresystem and to explore the design space regarding differentoptimization strategies.
To combine platform modeling and function mapping UMLartefacts can be mapped directly on components in a compo-nent diagram. This is depicted in figure 7. Therefore, holisticsystem modeling can be done in an integrated modeling designflow.
Fig. 7. Mapping of Behavior Elements onto Target Architecture Components
IV. GENERATION OF EXECUTABLE MODEL
The methodology of our holistic system modeling approachenables to perform model transformations leading to both amodel-based platform refinement and an automatic generationof virtual prototypes starting from the common data modelin UML. The transformation steps can be made on differentlevels, e.g. a model-to-model transformations processing XMLmodel code, and depending on further analysis and explorationprocesses which are based on component characteristics. Thisdesign flow is depicted in figure 8.
Fig. 8. General Design Flow of Holistic System Modeling
In the model-to-model transformation step, further UMLprofiles are applied to transform the system model to amodel with domain-specific semantics. The resulting systemmodel itself serves as a basis for further refinement stepsand the virtual prototype generation. The UML profile UMLfor SystemC [7] maps UML elements to SystemC workingmodels and therefore maintains the separation of computationand communication which reflects our modeling approachexplicitly.
Performing these model-to-model transformations realizesa consistent interface to the model code generation processwithout doing a direct code transformation from XML codeto SystemC.
In contrast to system modeling process which uses inputcharacteristics like IP-XACT component descriptions for UMLrepresentation, the generation approach is based on the con-crete component models of the corresponding system elements(cf. figure 9).
Fig. 9. Generation of an Executable Model in SystemC
By combining the system modeling and concrete componentmodels the macro-architecture, which has been developedthrough the UML modeling and function mapping process, istransferred into a micro-architecture. This micro-architecture,which depends on the transformation steps mentioned above,and of course the desired abstraction level, is transformed intoSystemC.
In listing 1, a SystemC module is generated to implement aUML processor component. For each function, which has to beexecuted on this processor, a SystemC process is being created.Further elements of the component model, e.g. registers,are mapped onto SystemC data structures with suitable datatypes. Additionally to that, a convenient API is generated tooffer a uniform access to component elements. This approachprovides dedicated interfaces from the development of func-tionality to the underlying target platform.
9
� �#include <systemc.h>#include ” ahb master interface .h”
class cpu1 : public sc module{
public :sc port<AHB MASTER> initor port;...
sc bv<32> reg1; // register 1...
void function1 () ; // specified function...
sc bv<32> getValueOfReg1; //convenient method...
cpu1(sc module name name) : sc module(name){
SC METHOD(function1);...
}};� �
Listing 1. Generated Component Module in SystemC
To manage component interconnections at an abstractionlevel just below considering only communicating processes,SystemC channel communication is generated to implementboth SystemC and IP-XACT interface concepts. An excerptof the generated code is shown in listing 2.� �#include <systemc.h>#include ” ahb master interface .h”
template<typename T>class RW TRANSACTION : public sc channel, public
AHB MASTER, ...{
public :void read(T&);...
RW TRANSACTION(sc module name name) :sc module(name)
{...
}};� �
Listing 2. Generated Communication Channel
V. CONCLUSION
In this paper we have presented an approach to modelboth the target architecture and the behavior of an embeddeddistributed system in a holistic way. Starting from a compo-nent library, which is generated from IP-XACT componentdescriptions, UML serves as an underlying common datamodel for this system modeling process. The componentgeneration approach can be easily integrated into UML designenvironments. By mapping the system behavior onto instancesof the component library we are able to generate an abstractsystem model which can be refined to an executable model inSystemC.
REFERENCES
[1] K. Keutzer, S. Malik, A. R. Newton, J. Rabaey, A. Sangiovanni-Vincentelli. System level design: Orthogonalization of concerns andplatform-based design. IEEE Transactions on Computer-Aided Designof Integrated Circuits and Systems, 19(12), 2000.
[2] SPIRIT Consortium. IP-XACT, Schema v1.4, 2007. http://www.spiritconsortium.org/XMLSchema/SPIRIT
[3] Object Management Group (OMG). UML Profile for Modeling andAnalysis of Real-time and Embedded Systems (MARTE), 2007. http://www.omgmarte.org
[4] Object Management Group (OMG). http://www.omg.org[5] S. Partners: Systems Modeling Language(SysML) Specification 0.9.
SysML Partners, 2005. http://www.sysml.org[6] Open SystemC Initiative (OSCI). SystemC. http://www.systemc.org[7] E. Riccobene, P. Scandurra, A. Rosti, S. Bocchio: A UML 2.0 Profile
for SystemC. STM Technical Report, 2005.
10
Using MARTE in a Co-Design MethodologyAli Koudri
Thales Aerospace [email protected]
Denis AulagnierThales Aerospace Division
Didier VojtisekIRISA
Philippe SoulardSodius
Christophe MoySupelec
Joël ChampeauENSIETA
Jorgiano VidalLab-STICC
Jean-Christophe Le LannThomson
Abstract—The Model Driven Architecture is a promisingapproach aiming to fill the productivity gap due to the increasingtechnology and time to market pressure. In the field of real timeembedded systems, this approach requires the use of well-adaptedformalisms in a reliable process that guarantees the quality of theproducts. MARTE, the new standardized UML profile, providesthose formalisms that are applied in the process defined in theMoPCoM SoC/SoPC research program, aiming to develop SoCand SoPC applications. In this paper, we discuss the main phasesof this process and their use of MARTE.
I. INTRODUCTION
Nowadays, embedded equipments rely more and more oncomponents such as System on Chip (SoC) or System on Pro-grammable Components (SoPC) based on Field ProgrammableGate Array (FPGA) for low volume of production.
Embedded applications require more and more computingresources. These needs can be fulfilled by SoC / SoPC integrat-ing on the same component analog circuits, hardwired ASICGates, programmable logical cells, memory blocks, high speedlinks, DSP and processor cores. Nevertheless, the SoC/SoPCdevelopment requires challenging productivity improvement tobe able to address the component design complexity[ITR07].
Moreover, some embedded applications are constrainedby certification norms like ARP-4754 (system), DO-178B(software) and DO-254 (hardware). In such case, SoC/SoPCdevelopments have to be handled by rigorous methodologiesbased on well-adapted formalisms[KCA07].
In this paper, we discuss a new methodology to developSoC/SoPC applications. This methodology is based on UMLand MDA (Model Driven Architecture), and takes into accountthe achievements of co-design community. MDA[OMG03],promoted by the OMG (Object Management Group) replacesclassical waterfall process (specification, design, coding), bya succession of models transformations, among these models:
• CIM (Computation Independent Model) models the re-quirements for the system and how the the system willbe used,
• PIM (Platform Independent Model) is the view of theapplication independent from the target platform and canbe considered as a functional description,
• PM (Platform Model) represents the target architectureused to implement the application,
• PSM (Platform Specific Model) results from the mappingof the PIM on the PM.
Actually, several PM of the SoC/SoPC Platform with dif-ferent levels of abstraction are required to achieve the finalimplementation. For each PM, the process of allocation resultsin new PSM and analysis models. This approach enables toincrease flexibility, reuse and separation of concerns.
The MDA approach was initially proposed in the contextof software development and can be applied in the co-designdomain. Indeed, "MDA notions" have been introduced longtime ago in this field. For example, the Y-Chart methodologyproposed by Gajski and Kuhn identifies behavioural, structuraland geometric viewpoints[DR83].
Compared to conventional co-design methodologies, the useof UML/MDA for SoC/SoPC development enables to takeadvantage of the standards and the tooling developed by theUML/MDA community, such as the new UML profile forModeling and Analysis of Real Time Embedded Systems(MARTE)[OMG07]. This profile enriches UML adding newnotions for real time systems such as Non-Functional Prop-erties or Time Access. Those features are seen in the sectionIII.
In this paper, we present a new Co-Design methodologydefined in the MOPCOM research project, aiming to providea full MDA compliant tool to design SoC/SoPC applications.In this methodology, system analysis follows the TelelogicHarmony
TMSystem Engineering process, based on the use
of SysML[OMG06], improved with the use of MARTE. Itis then refined to address platform and allocation modeling.Three levels of abstraction have been defined to describe theplatform on which the application is mapped (see fig.1):
• APA (Abstract Platform Architecture) considering theplatform as a set of basic services without notion of time,
• EPA (Execution Platform Architecture) refining the APAmodel taking into account software and hardware natureof APA components and timing constraints,
• DPA (Detailed Platform Architecture) detailing the EPAmodel, taking into account other constraints (power con-sumption, surface, etc).
In order to favor analysis, reuse or separation of concerns(computation / communication), the description of the com-
11
Fig. 1. MoPCoM overview
munications are described following the TML 2 standard asdefined by the OSCI [Ini07]. This allows the same designspace exploration allowed by different TLM levels (PV, PVT,CC) and the separation of concerns allowed by the MDAapproach. The Programmer View (PV) level captures theSoC/SoPC architecture without clock or explicit timing. Itfocuses on functional correction based on the execution ofthe underlying Model of Computation. Timing concern istaken into account in the Programmer View + Time (PVT)level where data size and computation duration are describedfollowing the non functional requirements. Only the CycleCallable (CC) level allows the fine verification of all thoseproperties.
At each level, several analysis models (performance, powerconsumption, etc.) can be generated from each allocationin order to validate design choices. This approach enablesearly errors detection and design space exploration withshorter simulation time. Moreover, in order to add meaningfulproperties to our methodology (predictability, maintainability,improvability, etc.) and automate it, we have used the SPEMprofile[OMG05] to formalize it.
In this paper, we present our use of the UML MARTEprofile through each phase of our methodology and we discussthe encountered problems from implementation or conceptualpoint of view.
II. RELATED WORKS
The relevance of model based approaches in Co-Designhave been widely discussed by the literature. In [BDH06],authors enumerate the main advantages of such approaches:cost decrease, silicon complexity handling, productivity in-crease, etc. Although several methodologies based on the useof UML/MDA have been applied, UML were not tailoredto design SoC/SoPC applications. Then, it was extendedand tooled by each of those methodologies, thanks to theprofiling mechanism provided since UML 1.3. For example, in[BDDM04], authors propose extensions to describe IntensiveSignal Processing Applications in a profile called ISP UMLProfile. In [RSRB05], authors apply a SoC Design Methodol-ogy based on the use of a UML profile called UML for Sys-temC Profile. This profile allows direct mapping between themodels and the concepts of the SystemC language. The samekind of approach is presented in [WZZ+06]. A SystemC UMLprofile is used to generate a TLM/PV SystemC code skeleton.In [CSL+], a design environment called Metropolis and aimingto design embedded systems is proposed. It tailors UML inorder to describe execution platforms and their refinements.They provide set of stereotypes representing structural partsof the platform and corresponding model of computation.
In [RSRB07] a development process for embedded systems
12
called UPES1, based on the use of SystemC profile, is pre-sented.
It is interesting to notice how, through all those approaches,common needs like platform and allocation description atseveral levels of abstraction are fulfilled by different ap-proaches. Some of them propose a direct mapping of theplatform concepts to the target languages while others usetarget languages as concrete syntax in purpose of generationor execution. The problem with those approaches are thedependency to the tools implementing very specific profiles orDSL (Domain Specific Languages). With the standardizationof the MARTE profile, we think this drawback will be handledby the use of common formalisms to describe real time andembedded systems.
III. USE OF MARTE IN THE MOPCOM SOC/SOPCRESEARCH PROJECT
The MoPCoM process is a Co-Design Process based on theuse of models and transformations. Since one of the main fea-tures of the MDA is the separation of concerns, there is a needto dispose of well-adapted formalisms to describe each part ofthe MDA model. For several reasons, such as communicationimprovements or tooling, we have made the choice to usestandardized meta-models and profiles. The new standardizedUML MARTE Profile add semantics to UML for Real timeEmbedded System Modeling. This profile is organized aroundseveral packages capturing different concerns :
• The Non Functional Properties (NFP) package enablesto describe features that are not directly related to thebusiness model (performance, memory usage, power con-sumption, etc.) and mechanisms to attach them to modelelements,
• The Time package enables modeling of time structure andaccess (continuous time, clock, etc.),
• The Generic Resource Modeling (GRM) package enablesmodeling platform resources from high level perspectiveand mechanisms to manage access to those resources,
• The Allocation package enables modeling of spatial andtemporal allocations,
• The Detailed Resource Modeling (DRM) package allowsmodeling of hardware and software resources at severallevels of granularity; it contains two sub-packages en-abling the modeling of Software Resource (SRM) andHardware Resource (HRM),
• The Generic Quantitative Analysis Modeling (GQAM)package allows several types; It contains two sub-packages for modeling Performance Analysis (PAM) andSchedulability Analysis (SAM).
Table I sum up the requirements of the process and for-malisms that satisfy those requirements. The system proper-ties, measurable or not, like power consumption or latency, canbe expressed using the Value Specification Language (VSL)provided by MARTE at each stage of the process.
1Unified Process for Embedded Systems
MoPCoM Process Requirements SolutionsModel Computational IndependentModel
SysML + MARTE NFP and RTE-MoCC
Model Platform IndependentModel
SysML + MARTE NFP and RTE-MoCC
Model Abstract Platform Architec-ture
MARTE GRM and NFP
Model Execution Platform Archi-tecture
MARTE DRM + NFP + Time
Model Detailed Platform Architec-ture
MARTE DRM + NFP + Time
Model Allocation (PIM toAPA/EPA/DPA)
MARTE Allocation + NFP
Model Analysis Models MARTE PAM and SAM
TABLE IMOPCOM PROCESS REQUIREMENTS
A. System Analysis
The system analysis goes from the requirements analysisto the system design and is covered by the SysML profile[OMG06]. Since this part is not really in the scope of thispaper, we will just give a quick overview in the followingpoints:
• requirements elicitation,• static validation of the requirements,• manual transformation of the requirements into use cases
and interactions,• use cases validation through simulation,• identification of the subsystems,• operational contracts allocation,• interaction refinements,• system design validation.
During this stage, we use some concepts of the NFP packagesin order to describe the required quality of services in termsof real-time features of behaviors and interactions. At the endof this stage, an annotated functional architecture is providedfor following steps, including allocations and refinements.
B. Abstract Platform Architecture
The platform is defined as a set of resources like processingresources, communication media or storage resources. Thepurpose of this level is to describe applied mechanisms inorder to realize high level functions. Communications betweenAPA blocks are point-to-point and realized through abstractchannels providing set of basic services allowing data trans-port. Actually, what we aim to describe at this level is theunderlying model of computation supporting the executionof the application and since we just want to demonstratethe functional correction of this model, it is thus untimed.Synchronization mechanisms ensure the characterization of thecausal relations between processing elements and then ensurethe predictability of the system behavior. The fact that themodel is untimed doesn’t mean that timing constraints inher-ited from the application model are not taken into account.Functional delays can be then inserted into the APA model,regarding the functional constraints.
13
Once the platform has been defined by the software orhardware engineering teams, allocation can be modelled usingwell-adapted formalisms provided by the allocation package ofMARTE. The allocation can be of spatial, temporal or hybridnature. Since many allocations with different characteristics(performance or schedulability) are possible, models of al-location are concerned with the functional correctness issue.The figure 2 summarizes issues related to the allocation atthe APA level. The application is modelled through businesscomponents communicating through (a)synchronous operationcalls or events send/reception while the platform is mod-elled through APA blocks communicating through channelsimplementing data transport services. The execution semanticdescribed in the business model must be verified through theallocation. Since the APA platform is untimed, there is nonotion of protocol at this level.
Fig. 2. APA allocation
In order to describe the APA platform, one need to describeresources from a high level perspective, without prejudging oftheir hardware or software nature, and take into account theirquality of service. The GRM package of MARTE provides allneeded stereotypes and tagged values to represent resources(computing resources, storage resource, communication me-dia, etc.) and their use. This package is used in conjunctionwith the NFP package for the quality of services and TimeModeling package for timing constraints. The GRM packageprovides also mechanisms of synchronization and resourcemanagement that fulfills the needs for APA modeling. Thepackage Allocation Modeling provides all needed stereotypesto allocate business model to APA platform. Since an alloca-tion comprises at least one application end and one executionplatform end, we need to constraint the set of possible map-pings for this level refining the allocation definition.
C. Execution Platform Architecture
The MOPCOM EPA platform level aims at providing amore precise platform than the APA level : while APAfocused on point-to-point communication, EPA provides moredetails with respect to the expected final topology on thesystem. The right methodological tools at this level are clearlyMARTE sub-profile HRM – Hardware Resource Modeling onwhich MOPCOM relies. Concerning the usage of MARTE,
the stereotypes used here are hwComputingResource (proces-sor,...), hwCommunication( bus,...).
EPA is geared towards architects willing to depict globalscenario of data movement over the chip and computingresources, without committing to final IP choice. EPA is thusfundamental to preserve the representativity of applicationwith respect to the platform, while enabling fast design spaceexploration and high-speed simulation, based on generic high-level components.
In this sense, many hardware resources must be adequatelyidentified at this level, without over-specifying them, which isoften the case when architects are not provided with appro-priate tools to help their specification. A natural companionmodeling concept of EPA is transaction-level modeling, aspromoted by Gajski and SystemC community in general.
Among those resources, communication media like buses,NoCs and buffering medium need to appear in EPA (the rightstereotypes here are HWI/O and HWStorage). Beyond thecommunication aspects, computing resources are also includedin this model, possibly still in an abstract (behavioral) version.For instance, instead of describing a real RISC processoror accelerator, EPA proposes to alleviate the need for deephardware description and invites to keep the functions executedby these processing elements as the representative of theblocks themselves.
Thus a wrapper needs to ensure that the function canindeed have access to the communication media : here weprone a simplified version of generic DMA at the I/O ofthe functional data-intensive blocks, possibly assisted withcontrol/status registers that ensure the high-level control of theapplication in a processor-like manner. Using this approach, itis possible to set up dummy experiments to test these notionsand their adequacy to a broader set of other experiments. Inthe following drawing, we depict typical experiment withinreach of an EPA model : the goal is to move data from DDRzones to other DDR zones, after some modifications executedon the set of data. A global controller, mimicking a micro-controller/processor, observes the completion of the variousdata transfers in order to enable the next transfers. Entire datastructures can be moved from one location to another withoutany serialization mechanism to low level data representation.As a consequence of this separation of concerns, early ap-plication porting debug activity can start, while studying theunderlying lower level mechanisms constraints that need to befulfilled to respect the expected final behavior.
Clearly here, the EPA level envisions the mapping pro-cess as a simple binding of application functions to pro-cessing elements and point-to-point communication links toconcrete communication elements, with no further notion ofcompilation to dedicated binary format, nor the resort toISS/interpreters : functions can still be seen as abstract tasks,just as in the APA level. Note that some blocks or units maybe in charge of executing several functions : in this case, thiscoarse grain resource sharing then assumes the presence of abasic abstract arbitration mechanism.
The performances of the final hardware cannot be mea-
14
Fig. 3. EPA typical experiment : data are moved from one location toanother, through well identified communication links, possibly simulated at abehavioral level, abstracting away details about finer details.
sured at the EPA level. However, the unambiguous iden-tification of computing resources types allows for analysisand parametrized estimations : we keep as much room aspossible for architectural exploration, by tuning these pa-rameters adequately. The metrics on which it is possible tofocus on are the channels required bandwidth and relativecomputation power of the processing units. MARTE SAMpackage (schedulability analysis model) are clearly in line withthe requirements at the EPA level. For instance we reinforcethe EPA structural model with behavioral scenarios with thehelp of Message Sequence Charts : synchronization aspects oflocking/unlocking buses can be handled through (Meta-class)BasicInteractions::Message, even if it has been promoted withOS in mind. In the same manner, many elements of PAMpackage seem adequate to analyze non-functional propertiesespecially concerning communication side. Their exact con-crete usage is still under study.
As emphasized here, EPA prones to resort to behavioraldescriptions instead of deeply detailed descriptions. For in-stance, concerning the processors, the further refinement toreal binary code (on the embedded SW side) and cycle & pinaccurate hardware will be treated in the ’next’ level, i.e DPAlevel, where measures becomes meaningful. The same appliedfor communications, where the complete protocols will needto be fully modeled.
One interesting question is about the minimum set ofhardware features to embed in this EPA level so that themodel of computation can be implemented either manuallyor handled by the MDA tool-flow : register control, DMAcontrol etc.
D. Detailed Platform Architecture
The DPA level aims to provide all required information toenable RTL code generation. The platform is defined as a setof IPs communicating through buses and all transactions areimplemented using refined and precise protocols.
The DPA level refines the EPA level as follow:• Introduction of hardware clock(s) – all synchronous ele-
ments must be connected to a clock,• Definition of a cycle accurate communication protocol
– all communications must be well defined in terms ofsignals and clock cycle,
• Detail of Physical hardware Layout – for example: cardlayout and power consumption.
Although the MARTE profile provides a set of stereotypesenabling to define buses and behavior, it does not enable anexplicit way to precise protocols. The constraints related toprotocols are expressed using NFP annotations. In order tofaster the design and favor reuse, one can use libraries of stan-dard protocol and generate needed wrappers. The MoPCoMproject aims at providing such libraries.
The figure 4 shows the main issues related to the allocationat the DPA level. As the execution platform is detailed,the application must be refined to precise cycle accuracy ofthe behavior. Designers must then provide complementaryviews of the platform showing their physical details such asprocessor type, ISS, registers or pins. This can be achievedusing stereotypes provided by the HRM MARTE sub-profile.
Fig. 4. DPA allocation
The consistency of the behaviors and the communicationsmust be kept through the refinement. Indeed, the model ofcomputation defined earlier is detailed with information relatedto time or data. Then, the desired performance can be checkedat this level.
The last refinement to achieve an optimal configuration ofthe DPA blocks (physical characteristics) must be providedat this stage and the HRM sub-profile contains a packageproviding all needed stereotypes to achieve this goal. Theyare classified in two types:
• HwLayout: Channel, Card, Channel or Port,• HwPower: Power Supply, Colling Supply or Battery.For instance, several tags are associated to the HwPort
stereotype such as pin number, area, weight, etc. Then, al-location of the functional model to this very refined hardware
15
platform definition enables the verification and validation ofthe non-functional properties required by the functional modelas quality of service.
Several modeling constraints must be applied in order toallow an automatic code generation. Among them:
• HRM stereotypes must be used to model all hardwareelements and all required tagged values must be set,
• Protocols must be specified using state-charts,• Every synchronous element must be connected to a clock.The model provided at the end of this stage is transformed
into a RTL model for code generation. The target meta-modeland code generation rules are provided by the Sodius Companyin their MDWorkbench Tool.
IV. DISCUSSIONS
The development methodology we have presented above isbeing experimented on a video application for SoC and a RFdigital receiver application for SoPC. Despite we think thatMARTE can fulfil most of the requirements of a modellinglanguage for SoC/SoPC design and analysis, we faced somelimitations applying MARTE. Those limitations are eitherrelated to the implementation of the profile or missing conceptsin the profile.
• Allocation: MARTE proposes to specify the "allocate"relationship between business components and resourcecomponents with notation based on a UML dependency(with "allocation" stereotype). This graphical approachcan be very cumbersome and messy for large models.Some tooling, using widgets for example, could be de-veloped to facilitate the allocation activity.
• Model of Computation and Communication: MARTEfoundation enables to define alternative MoCC. Mod-elling or implementation of embedded applications gener-ally rely on heterogeneous MoCCs such as SynchronousData Flow (SDF), Communication sequential process(CSP), Petri Net (PN), Kahn Process Network (KPN).These specific MoCCs should be introduced in MARTE.
• Action Semantics: In the purpose of executing and test-ing models, UML has introduced the Action Semanticsto provide software independent language specificationfor actions in their models. Nevertheless, those actionsemantics have been defined in the context of softwaredevelopment, and then do not integrate concerns fromother domains like system or real time domain. Typically,actions defined by the UML specification are related toother UML concepts and since new concepts have beenintroduced in MARTE, we think it would have beeninteresting to add meaningful actions related to them andalso provide associated concrete textual syntax.
V. CONCLUSION AND FUTURE WORKS
In this paper, we have discussed a co-design process calledMoPCoM based on the use of the MARTE profile. For eachphase of this process, we have presented the selected stereo-types of the profile and constraints related to their use. Wehave outlined the main encountered problems from conceptual
and implementation perspective. Future works are related toVHDL and SystemC code generation after the allocation of theapplication on the Detailed Platform Architecture. This devel-opment is done using MDWorkbench transformation toolingfrom Sodius2. Further works will be carried out on modellingand implementing dynamically reconfigurable applications.
ACKNOWLEDGMENTS
The research program MOPCOM3 SoC/SoPC is supportedby the French National Research Agency (ANR), the "clusterof clusters" and "Media and Networks" from Brittany and Paysde la Loire regions. The program partners are the end-usercompanies Thales, Thomson, Sodius as an MDA tool providerand the academic research institutions ENSIETA, LESTER,Supelec and INRIA.
REFERENCES
[BDDM04] Pierre Boulet, Cédric Dumoulin, J-L Dekeyser, and Philippe Mar-quet. Uml 2.0 structure diagram for intensive signal processingapplication specification, 2004.
[BDH06] Pierre Boulet, Cédrid Dumoulin, and Antoine Honoré. Modeldriven engineering for system-on-chip design. In From MDDConcepts to Experiments and Illustrations, pages 91–109. ISTEltd, 2006.
[CSL+] Rong Chen, Marco Sgroi, Luciano Lavagno, Grant Martin,Alberto Sangiovanni-Vincentelli, and Jan Rabaey. Uml andplatform-based design.
[DR83] D.D.Gajski and R.Khun. Guest editor introduction : New vlsitools. In IEEE, editor, IEEE Computer, volume 16, pages 11–14. IEEE Computer Science, 1983.
[Ini07] Open SystemC Initiative. Osci tlm2 user manual, 12 2007.[ITR07] ITRS. The international technology roadmap for semiconductors
: Design, 2007.[KCA07] Ali Koudri, Joel Champeau, and Denis Aulagnier. Fpga rf
transceiver development based on uml mda approach. DAC,2007.
[OMG03] OMG. Mda guide version 1.0.1. Technical report, ObjectManagement Group, 2003.
[OMG05] OMG. SPEM 1.1. Technical Report ptc/05-01-06, ObjectManagement Group, 2005.
[OMG06] OMG. Sysml profile. Technical Report ptc/06-04-03, ObjectManagement Group, 2006.
[OMG07] OMG. Uml profile for marte, beta 1. Technical Report ptc/07-08-04, Object Management Group, 2007.
[RSRB05] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. A socdesign methodology involving a uml 2.0 profile for systemc. InDATE ’05: Proceedings of the conference on Design, Automationand Test in Europe, pages 704–709, Washington, DC, USA,2005. IEEE Computer Society.
[RSRB07] Elvinia Riccobene, Patrizia Scandurra, Alberto Rosti, and SaraBocchio. Designing a Unified Process for Embedded Systems.In Fourth International Workshop on Model-Based Methodolo-gies for Pervasive and Embedded Software, pages 77–90. IEEEComputer Science, mars 2007.
[WZZ+06] Ting Wang, Xue-Gong Zhou, Bo Zhou, Liang Liang, and Cheng-Lian Peng. A MDA based SoC Modeling Apporach using UMLand SystemC. In Proceedings of the sixth IEEE InternationalConference on Computer and Information Technology (CIT’06),pages 245–245. IEEE Computer Society, september 2006.
2http://www.sodius.com & www.mdworkbench.com3http://www.mopcom.fr
16
Evaluating MARTE in an Industry-Driven Environment: TIMMO's Challenges for AUTOSAR Timing Modeling
Huascar Espinoza1, Kai Richter2, and Sébastien Gérard1
1 CEA LIST, Model-Driven Engineering labs Point Courrier 94 91191, Gif sur Yvette Cedex, France {huascar.espinoza, sebastien.gerard}@cea.fr
2 Symtavision GmbH Frankfurter Straße 3B 38122 Braunschweig, Germany [email protected]
Abstract The TIMMO project is defining a timing framework complementing the AUTOSAR standard, which aims to ease integration of software pieces into predictable sys-tem-level applications. In this paper, we explore MARTE from three TIMMO perspectives: modeling concepts to enable timing analysis, expressiveness to cover common issues in automotive applications and, best practices for managing complexity in modeling languages.
1 Introduction The AUTOSAR [1] [2] partnership has defined a stan-dard software infrastructure to enable modularity, scal-ability, transferability and re-usability of automotive applications among projects, variants, suppliers, custom-ers, etc. However, the newly enabled design flexibility cannot be fully exploited because new problems appear that are related to non-functional performance and timing dependencies among software components.
In 2007, several European OEMs, Tier-1s, SW suppliers, tool vendors and universities have joined in the EU-funded TIMMO1 [3] project to define a Timing Aug-mented Description Language (TADL) as a supplement to the AUTOSAR standard to overcome this deficiency. But it is not so simple [3].
For the definition of TADL, TIMMO needs syntax and semantics for timing properties of AUTOSAR systems. Key questions include:
• Which concepts must be considered?
• How to define timing properties?
• Where and how to annotate best?
• How about implementation dependent properties?
• How to deal with black-box components?
The TIMMO project has recently started identifying “pragmatic scenarios” in which timing models and analy-sis tools enable new design steps or increase product quality. From these scenarios, the requirements for "what is needed” is being derived in two ways: language con-cepts and tool infrastructure.
1 This document is partially based on the TIMMO project in the framework of the ITEA 2, EUREKA cluster Programme Σ! 3674. The work of the German partners has been funded by the German Ministry for Education and Research (BMBF) under the funding IDs 01IS07002 (B-I,K). The responsibility for the content rests with the authors.
Among others, TIMMO has started evaluating the MARTE (Modeling and Analysis of Real-Time Embed-ded systems) standard [10] as one possible input for TADL. MARTE supports specification of real-time con-strained systems. One of its goals is to enable designers to perform timing analysis directly from their UML de-sign tools, thus reducing the time required to prepare a model for analysis. MARTE has been recently adopted as an OMG standard, and hence, it is just starting to be tested into industrial projects (European: ATESST, SATURN, INTERESTED, and French projects: MeM-VatEx, Usine Logicielle, OpenEmbeDD).
TIMMO can benefit from that in two ways: (a) semanti-cally, because MARTE has a strong timing analysis basis and (b) syntactically, because MARTE has already de-fined a modeling language for many common timing aspects. A key challenge for TIMMO will be to select the right level of abstraction that can be integrated into (or at least aligned well to) the existing AUTOSAR meta-model and templates.
In this paper, we first introduce key AUTOSAR re-quirements and briefly summarize the dissemination plan of TADL. Then, key MARTE characteristic are reviewed in the context of the TIMMO requirements.
We subsequently analyze how well the MARTE struc-ture meets the existing AUTOSAR templates, and how TIMMO can most effectively exploit it.
We conclude with a recommendation-type of statement to TIMMO and MARTE.
2 AUTOSAR and Timing The main goal of AUTOSAR is to define a software architecture with standardized APIs and configuration files for application and basic software, which allows exchanging parts of the system’s software in ways that programmers know from Java or C++. Key goals are modularity, scalability, transferability and re-usability of software among projects, variants, suppliers, customers, etc. without the time-consuming and costly need to re-configure, port, and re-build the code.
It is important to understand that the primary objective of AUTOSAR is not solving timing problems in particular but supporting integration from a software-engineering perspective. However, system’s timing properties have a strong impact on key steps in the newly envisioned AUTOSAR methodology. For instance, adding a soft-ware component to an existing ECU potentially intro-duces non-functional timing and performance
17
interference with the original ECU software due to scheduling, arbitration, blocking, buffering etc., eventu-ally generating hard-to-find timing problems, including transient overload, buffer under- and over-flows, and missed deadlines that can finally make the new or the old functions or the entire ECU fail.
Not having a systematic timing analysis procedure is challenging future design processes, and there is increas-ing awareness within AUTOSAR that a timing model is needed. This gave rise to the TIMMO project in 2007.
3 TADL Usage Scenarios & Dissemination The Timing Augmented Description Language (TADL) will be a key result of the TIMMO project to be used as a complement to AUTOSAR templates. Requirements on TADL are derived from scenarios that the industry part-ners (TADL users) deliver, while the technology partners (tool vendors and academia) contribute conceptual input. Bridging the gap between the API-centric software-engineering view and a math-centric timing analysis view is one key challenge, not only for the definition of the TADL but also to keep the discussion focused within TIMMO.
Of course, the closer the link to existing AUTOSAR templates, the higher the acceptance in practice will be. On the other hand, the alignment with AUTOSAR must not come at any price, so also recommendations for changes within AUTOSAR are possible, but must be carefully discussed. One already identified deficiency of AUTOSAR is the limited abstraction. AUTOSAR covers only the lower two layers of the EAST-ADL -ADL for the automotive domain developed in the ATESST pro-ject- layered architecture modeling proposal. TIMMO aims at including at least one more view, possibly the function development view that is known from tools such as Matlab/Simulink.
This discussion will further be influenced by another key TIMMO goal: the description of a new timing methodol-ogy that is enabled by the new TADL and shall be prac-tically supplemented by tools and also aligned with the AUTOSAR methodology. Here, also the link to design tools is important.
Finally, TIMMO will regularly check the work on the TADL definition with AUTOSAR progress and likely align its work direction with a new AUTOSAR timing sub-group that aims at introducing timing aspects into one of the next releases. This timing subgroup will also exploit early TIMMO results because AUTOSAR ends 2009, before TIMMO’s results are finalized.
4 Expectations to MARTE Use All TIMMO partners believe that the MARTE standard can contribute valuably to TIMMO. However, there are some critical points that require consideration, especially resulting from TIMMO’s highly industry-driven pragma-tism and its dissemination plan:
Only few designers (in contrast to researchers) in the automotive industry have used UML. There are already many automotive-specific own standards. Therefore, individual, well-chosen UML concepts can definitely make many friends here. But any approach to introduc-
ing UML (or any UML profile) as the Holy Grail will definitely fail in reaching its target audience.
The range of applications and areas of knowledge that are in the scope of MARTE is broader than the current TIMMO scenarios. Although all of them are related from the time- and resource-constrained perspective, different specialized actors, tools, and even computation para-digms are commonly involved. Consequently, it becomes natural that a number of modeling concepts and proper-ties in MARTE are not useful in the automotive domain. This aspect would do MARTE to be often rated “too big” (similar to EAST-ADL) for a use targeted in this domain. For instance, hardly any designer in the automotive in-dustry has ever heard of earliest deadline first (EDF) or least laxity scheduling. AUTOSAR has installed mecha-nisms that reject any attempt to introduce model ele-ments that are of no relevance for the envisioned use.
On the other hand, even though MARTE already covers many aspects of timing, some points of interest should be carefully evaluated. One important example is the speci-fication of over- and under-sampling in end-to-end tim-ing chains (a pattern commonly found in control systems). Others are related to the elements of the overall AUTOSAR software architecture such as runnables inside tasks and signals inside frames.
Accordingly, we define a set of principles to evaluate to what extent MARTE may help for the TADL definition:
• Beyond syntactical and technological aspects, we fundamentally assess the adequacy of MARTE from a conceptual and semantic viewpoint.
• The evaluation of missing points needs to be objec-tive by clearly identifying whether it implies a con-ceptual, semantic, or parameter insufficiency. This raises the problem of improvement and extensibility of MARTE, which is an important goal of this paper.
• The benefit of a modeling language needs to be measured according to the decision maker’s ability to design a timeliness correct system. Therefore, it is valuable to assess capabilities for specifying different candidate architectures and quantitative scenarios.
• Another facet that MARTE may contribute is to fos-ter software engineering best practices in modeling language design. This includes complexity manage-ment mechanisms such as model views, separation of concerns, and model composition.
We expect that the exploitation of MARTE in TIMMO will be driven by these requirements. The next sections highlight key MARTE concepts and language character-istics w.r.t these requirements.
5 MARTE Review in the TIMMO Context Rather than elaborating upon every detail, we discuss only the most important aspects related to the aforemen-tioned expectations.
5.1 Global MARTE Organization
In order to ease its adoption process, MARTE defines a modular approach to organize its language constructs, with the ability to select only those parts of the language that are of direct interest. It starts from a set of language
18
packages called “extension units”, and then groups them in high-level packages with different abstraction and refinement levels.
Thus, a “foundational” high-level package provides a language basis to model non-functional properties (NFPs), time concerns, resources, components, and oth-ers. The foundational concepts are then refined in two packages to fit with design and analysis of embedded systems. The MARTE design model package deals with the specification of applications, as well as with model-ing of software and hardware execution platforms. The MARTE analysis package provides modeling capabili-ties for non-functional analyses, such as scheduling and performance analyses.
Each extension unit is formally specified in two stages. The first defines the conceptual constructs describing the problem that is understandable to the widest possible range of stakeholders. The product of this stage is called the domain model of the profile. In a second stage, this solution-independent specification is then implemented as UML extensions.
In this paper, we cover the evaluation of the domain model only. It is important to understand that this do-main model has been created as free as possible from considerations related to specific solution technologies so as to not embody any premature decisions that may hamper later language use. This means that this domain model can be concretized not only as a UML profile, but as an independent modelling language, possibly imple-mented as an XML schema, as well. Note that, although the MARTE domain model is specified in the form of a metamodel with a textual semantic description (like AUTOSAR), it represents only conceptualization entities synthesizing the “universe of discourse”.
In the remaining of this section, we briefly evaluate this conceptual domain model following TIMMO needs.
5.2 Real-time Analysis Concepts
The main interest here is to evaluate the synergy between AUTOSAR and a subset of MARTE concepts related to timing evaluation by establishing connections with the simulation and analysis techniques and tools targeted by TIMMO.
The main analysis techniques in the scope of TIMMO are scheduling-aware timing analysis. This kind of tech-niques offers a mathematically-sound way to determine whether a system will meet its timing requirements and how it could be balanced (e.g., task allocation, priority assignment, component deployment) by still respecting timeliness. Here, the influence of scheduling on the tim-ing and performance of a system is crucial to calculate guaranteed bounds on responses times and resource processing loads.
When creating a modeling approach for specifying em-bedded systems, the well-known Y-Chart scheme [8] provides a strong foundation. This approach specifies how the different models of the application and the HW/SW resource platform are put together to build the global system model. This feature attempts to enhance the modeling practices to ease retargetability of logical
model elements onto execution platform models possibly stored into reusable libraries.
As analysis models are intended to be integrated within existing application and resource models, MARTE was especially interested on discerning modeling elements according to the Y-Chart approach (see Fig. 1).
Within the application model, so-called “workload be-havior” in MARTE, an environment view describes how often will events arrive and how much data are provided as inputs to the system, and how response events are generated in return by the system. In addition, workload behavior models provide information about the process-ing behavior that is used to execute the various tasks.
On the other hand, “resource platform” models provide information about the properties of the computing and communication resources that are available within a system, such as processor speed and communication bus bandwidth. The system model thereby captures informa-tion about the applications and the available resource platform of the system, and it also defines the mapping of application tasks to computation or communication resources.
The domain model for non-functional analysis in MARTE is organized around the notion of Analysis Con-text (Fig. 1). An analysis context is the root concept used to collect relevant quantitative information for perform-ing a specific analysis scenario. Starting with the analysis context and its elements, a tool can follow the links of the model to extract the information that it needs to per-form the model analysis.
Fig. 1 Organization of MARTE analysis concepts.
Due to the specific tools targeted by TIMMO (i.e., tim-ing analysis and simulation, essentially), it is key to bound system model elements to a particular analysis or evaluation context. As automotive applications become more complex, there often is a need to represent a system by multiple analysis models, corresponding to different application-platform allocations, abstraction levels, or different quantitative values of non-functional properties, requirements and constraints. The use of an explicit analysis context facilitates the preservation of consis-tency amongst separated model elements, and it is highly recommended to have such a modeling construct in TADL.
19
The level of abstraction of the concepts that would be adopted in TADL should be determined by the amount of detail needed to perform an acceptable system analysis. This will allow developers to ignore complex details in the process of modeling automotive software systems. On the other hand, these abstractions must not be too disconnected from the underlying system platform so that analysis results can be reliable.
In the current AUTOSAR specification, one impediment to integrate timing analysis is that the underlying compu-tational model of applications (components, ports, run-nable entities) is quite unlike the tasking models used in real-time analysis theory, and assumed in the underlying tools. One common approach to overcome this semantic gap consists in creating from the design model a sepa-rated analysis model view that matches better with ana-lytic models (see for example [5] [7]).
The MARTE specification approach allows for directly annotating existing functional models. In this way, the set of analysis extensions are considered as additional concepts to annotate the appropriate elements of the original (application and architecture) models as repre-senting concepts from the timing analysis viewpoint. The challenge in the AUTOSAR case lies in the identification of those analysis modeling constructs that minimize (application and architecture) model corruption while still allowing for extraction of analysis information.
For this purpose, we have identified those MARTE con-cepts that are necessary for timing analysis (Table 1). Note that some of them have a counterpart in AUTOSAR, while others are missing, at least in the current public version.
MARTE concept AUTOSAR concept End-to-end flow None Workload event TimingEvent Step (ExecStep, CommStep) Runnable Entity Execution Host ECU Communication Host None
Shared Resource None
Schedulable Resource (OS) Task Timing Observer None
Table. 1 Related concepts in MARTE analysis vs. AUTOSAR
We briefly summarize the semantics of these concepts as following:
End-to-end flow. It describes a unit of processing work in the system, which contends for the use of processing resources with other end-to-end flows. As a key feature, the processing of a given end-to-end flow can be distrib-uted on multiple processing nodes. This is considered by TIMMO as one of the main concepts missing in AUTOSAR for enabling end-to-end timing studies.
Workload event. End-to-end flows refer to a set of stim-uli requesting computations that are called workload events. From a specification viewpoint, workload events can be modeled by known patterns (e.g., periodic, spo-
radic, bursty), by trace files, or by workload generator models (e.g., state machine models). Although AUTOSAR already has the TimingEvent concept, which has a period as attribute, this is clearly not enough to perform timing analysis. The workload event element contains additional parameters for periodic and aperiodic patterns such as for example, jitters, burst parameters, and distributions among others.
Steps. Depending on the nature of its implementation, an end-to-end flow can be concretized in a single action executing into one processor or in a number of related actions into single or multiple processors. These actions are referred as “steps” in MARTE, and they may be assimilated as AUTOSAR “runnable entities”. Indeed, a step may represent a small segment of code execution as well as the sending of a message through a communica-tion media. The step concept has latency properties such as for instance worst/best/average execution times.
Execution and communication hosts. The MARTE analysis model distinguishes two kinds of processing resources: execution hosts, which include for example processors and coprocessors, and communication hosts, which include networks and buses. Processing resources can be characterized by throughput properties as for example processing rate, efficiency properties such as utilization, and overhead properties such as blocking times and clock overhead times.
A MARTE weakness here is that these properties are certainly insufficient to describe all the analyzable as-pects in some specialized buses used in the automotive domain (e.g., FlexRay). Although MARTE considers static schedules (time tables) for time-triggered systems, they were not formalized with concrete parameters.
Shared resources. When steps need to access common shared resources, the underlying scheduling mechanisms are typically implemented using some form of synchro-nization resource, (e.g., semaphore or mutex) with a protecting protocol to avoid priority inversions, such as FIFO or priority ceiling protocol. Note that this access mechanism is not explicit in AUTOSAR models.
Schedulable resources. Steps use the active resource services for execution by means of schedulable re-sources (e.g., OS threads or tasks) and communication channels (e.g., units conveying messages) characterized by concrete scheduling parameters.
In AUTOSAR, this element is commonly referred as an OS task, and has no explicit modeling element. However, identifying how runnables are mapped to tasks is consid-ered as a core problem in TIMMO. Some mapping sce-narios, which must be provided by the ECU configuration description, have been identified in AUTOSAR.
For instance, Fig. 2.a illustrates a mapping of runnables into tasks, and Fig. 2.b shows the equivalent with MARTE analysis annotations. It must be noted that the intention is not to evaluate the graphical formalisms, but to establish the expressiveness from a language view-point. More complex behavior and allocation patterns can be built in MARTE by using activity (or other be-havioral) diagrams.
20
Fig. 1 Organization of MARTE analysis concepts
Up to this point, we have evaluated some key concepts that may be useful for TIMMO. However, a lot of infor-mation for performing analysis is specified in time prop-erties. The next section explores some representative features that are required to evaluate timing correctness.
5.3 Time modeling
Beyond the qualification of non-functional annotations, timing annotations require a careful semantic definition closely related to application behavior and the different models of computation and communication. In the MARTE’s Time package, time is part of the behavior, not a mere annotation [12]. Moreover, this notion of time covers both physical and logical time. While the logical time is the basis to understand basic temporal notions, this is further refined to support precedence/dependency in presence of concurrency, clocked time abstractions to cover synchronous language abstractions (such as Esterel or SCADE).
Time observations and timing assertions. One key mod-eling feature in MARTE is the observation concept, which is specialized in instant and duration observations. An instant observation is a reference to a time instant during an execution, while a duration observation defines an observed duration interval in an execution. This is particularly useful when behavior models are explicitly specified. Indeed, providing marking points in behavior models, allows modelers to specify assertions (require-ments, constraints, properties) related to arbitrary points in an application behavior scenario. Some typical asser-tions has been embedded in MARTE ready-to-use pat-terns, such as for example jitters, relationships between different occurrences of the same event (by an occur-rence index), or conditional timing assertions (e.g., a deadline applies only if a certain data is available).
Timing observers. Timing analysis characterizes the system evaluation in terms of a set of timing require-ments and timing predictions. Timing requirements in-clude deadlines, maximum miss ratios and maximum jitters. Timing predictions are typically provided by analysis tools and include latencies, jitters, and other scheduling metrics. These aspects are modeled in MARTE by using the timing observer concept.
It is normal that AUTOSAR does not include this con-cept, given that a timing observer is purely a conceptual entity - i.e., it does not represent any run-time aspect - that is particularly useful to annotate and compare timing constraints against the timing predictions provided by analysis tools. Most of analysis tools [7], [5] provide means to specify this kind of information, which is more related with the exploration of constraint cases.
Over/under sampling modeling. A common pattern in end-to-end flows that is particularly important in control systems is over/under sampling. Automotive applications often consist of periodic tasks possible dependent through event or data interchange (signals). In order to perform reliable timing analysis, the semantics of differ-ent synchronization patterns must be specified.
MARTE provides the specification mechanisms to im-plicitly establish a partial order on how tasks actually behave [12]. In [12], the operational semantics is explicit and the different scenarios have been constructed in a formal way by using behavioral diagrams annotated with a notation of clock constraints. In this paper, we do not discuss on the technical details about over/under sam-pling specification. Rather, an important question in the TIMMO context is the usability of such specification mechanism by TADL end users. Note that while the MARTE notation requires certain specification effort, it may cover more semantic cases than a conventional modeling language (AADL in [12]). An important con-sideration in TIMMO should be to adopt a meet-in-the middle approach by balancing usability and flexibility.
5.3 Modeling non-functional properties
One fundamental aspect for TADL is the underlying system of data types supporting specification of non-functional properties. MARTE has the ability to encapsu-late rich annotations within non-functional values. For instance, consider a non-functional property named “la-tency”. Instead of declaring its meaning in an axiomatic way such as: “duration mean value in milliseconds measured in the platform X with an accuracy of 0.01”, the specification itself include all this information in a normalized syntax. For this purpose, the MARTE data type system includes the required data structure in a predefined library. Some examples of data types are Duration, DataSize, DataTxRate, Frequency and Power.
Additionally, assumed/guaranteed non-functional prop-erties can be annotated in component interfaces by using specialized constraint annotations (nfpConstraints). This is particularly useful to specify correct-by-construction component applications.
5.4 Modeling practices 21
Besides conceptual aspects, MARTE (and UML) can be regarded as a domain-specific language providing some good practices from the software engineering viewpoint:
Behavior models. The AUTOSAR metamodel, like most ADLs, centers in modeling the (software) architecture. Although these models are important for the initial AUTOSAR scope, behavior models are arguably the most important for timing analysis. If the system does not behave in a way that satisfies timing requirements, then it is useless regarding the TIMMO perspective. For the kind of analysis techniques evaluated in this paper, MARTE extensively uses sequence diagram (a behavior scenario highlighting the control flow) and activity dia-grams (a behavior specification of the inputs, outputs, and conditions for coordinating the different pieces of execution).
Views and model composition. When dealing with com-plex systems in general, a number of specification mechanisms are required to deal with model complexity. For instance, a model view is a typical abstraction that helps to divide a complex problem into smaller and com-prehensible parts. In order to process global models, e.g., for timing analysis, we must compose back these smaller parts in a consistent way. UML (and MARTE conse-quently) supports model composition by means of com-posite structure diagrams. The basic principle is to define usages of model elements in a given “context”. The idea of composite system models for analysis is to describe how information from multiple modeling arti-facts and views is to be joined/deployed, and how differ-ent non-functional properties are collected from these models. In [9], MARTE is used in practical system inte-gration scenarios, where multiple candidate configura-tions are evaluated.
Parameterization. Each analysis context may involve specific parameters to be evaluated. Particularly, sensi-tive analysis can be used at system design level to under-stand how “sensitive” are the overall results to a given parameter. Although the sensitivity analysis process may be fully delegated to analysis tools, there is an important need in design-level languages for addressing the correct parameterization (e.g., determination of dependent, inde-pendent, and critical parameters) and solution selection. In [11], the authors use the basic MARTE mechanisms to specify non-functional variables to compose multiple quantitative scenarios that are further evaluated to make efficient design decisions.
6 Conclusions In this paper, we have reviewed TIMMO goals and sur-veyed the most relevant modeling concepts in MARTE that can be useful for the timed augmented description language. There is no doubt that TIMMO can to a large part benefit from the valuable work that MARTE has done, both semantically (to yield analyzable models) and syntactically (to structure this information efficiently).
However, several issues must be considered that we have worked out in this paper:
• Which MARTE part is most important to look at? We recommend to look at the domain model with its con-cepts based on analytical scheduling models.
• TIMMO is currently identifying the AUTOSAR concepts relevant for scheduling and timing. We sug-gest taking into account the MARTE domain model during the TADL definition, but still keeping the lat-ter independent and clean.
• Completeness: MARTE does not capture all the knowledge and information needed to solve timing problems in the automotive domain, e.g. FlexRay.
• Oversize. MARTE has much more than required by TIMMO, like EDF. Hence, a subset must be selected.
• Beyond conceptual aspects, MARTE can bring some recommendations of good practices in design of de-scription language, which mostly come from the ex-perience of its incubation organism: OMG.
This shows that there are still open issues, and the best way to cooperate is still to be found. However, we have highlighted the likely value of possible starting points. We hope that this paper helps starting detailed interac-tion between TIMMO and MARTE participants and “associates”.
References
[1] AUTOSAR Partnership. www.autosar.org [2] AUTOSAR Partnership. AUTOSAR—Current results and
preparations for exploitation. In Proc. 7th EUROFORUM “Software in the vehicle”. Stuttgart, Germany, May 2006
[3] M. Jersak et.al. Timing-Modell und Methodik für AUTOSAR. Elektronik automotive, Special issue AUTOSAR, October 2007
[4] K. Richter, On the Complexity of Adding Real-Time Properties to the AUTOSAR Software Component Model. In Proc. OMER4 Workshop. Paderborn, Germany, Octo-ber 2007
[5] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter, R. Ernst. System Level Performance Analysis - the SymTA/S Approach. In IEE Proceedings Computers and Digital Techniques, Vol. 152, Is. 2, March 2005.
[6] O. Scheickl and M. Rudorfer. Automotive Real Time Development Using a Timing-augmented AUTOSAR Specification. In Proc. Embedded Real-Time Software Congress (ERTS), Toulouse, France, 2008
[7] J.L. Medina, M. G. Harbour, and J.M. Drake: MAST Real-Time View: A Graphic UML Tool for Modeling Ob-ject-Oriented Real-Time Systems. Proc. of the 22th IEEE RTS, pp. 245-256. December 2001.
[8] R. Chen, M. Sgroi, G. Martin, L. Lavagno, A. L. Sangio-vanni-Vincentelli, J. Rabaey: UML for Real: Design of Embedded Real-Time Systems, pp. 189-270, Kluwer Aca-demic Publishers, May 2003.
[9] H. Espinoza, “An Integrated Model-Driven Framework for Specifying and Analyzing Non-Functional Properties of Real-Time Systems”, PhD Thesis, University of Evry, FRANCE. Sept. 2007.
[10] OMG: UML Profile for Modelling and Analysis of Real-Time and Embedded systems (MARTE), version Beta 1, July, 2007
[11] H. Espinoza, D. Servat, and S. Gérard, Leveraging Analy-sis-Aided Design Decision Knowledge in UML-Based Development of Embedded Systems, SHARK-ICSE 2008. Leipzig, Germany. May 2008.
[12] C. André, F. Mallet, R. de Simone, "Modeling of Immedi-ate vs. Delayed Data Communications: from AADL to UML MARTE", ECSI Forum (FDL), September 2007, Spain.
22
Gaspard2: from MARTE to SystemC Simulation
Éric [email protected]
Rabie Ben [email protected]
Philippe [email protected]
Samy [email protected]
Smaïl [email protected]
Anne [email protected]
Jean-Luc [email protected]
Pierre [email protected]
LIFLUMR 8022 CNRS – USTL59655 Villeneuve d’Ascq
INRIA Lille – Nord Europe40 Avenue Halley
59650 Villeneuve d’Ascq
LAMIHUMR 8530 CNRS – UVHC
59313 Valencienne
Abstract
To efficiently use the tremendous amount of hard-ware resources available in next generation MultiProcessorSystems-on-Chip (MPSoC), new design methodologies andtools are needed to reduce the development complexity ofsuch systems. In this paper, we present an efficient MPSoCdesign environment, Gaspard2. It uses the new standardMARTE (Modeling and Analysis of Real-Time and Embed-ded systems) profile for high level system representation.Gaspard2 is based on a Model-Driven Engineering (MDE)methodology allowing to move from the primary modelingform to an executable platform. In our work, we targetSystemC code generation at the Timed Programmer View(PVT) level. To reach our objective, a compilation chain hasbeen developed, made up of several model to model trans-formations.
Keywords: MPSoC, MARTE, Gaspard2, MDE, transfor-mation, UML, SystemC
1. Introduction
At the same time as advances in technology allow to in-tegrate more and more transistors on a single chip, the em-bedded system applications get always more sophisticated.Although these two evolutions fit well in term of compu-tation power, the combination put a strong pressure on thedesigners’ capacity to design and verify the resulting verycomplex systems. To enhance the productivity, new designmethodologies have to be adopted for the development ofsuch large and complex Systems-on-Chip.
Nowadays, system design based on a high level mod-eling approach becomes increasingly attractive for differentreasons. First, designers may attain higher levels of abstrac-
tion allowing to focus on a particular domain space. Sec-ond, such approach offers a visual expression form makingeasier to understand the system and to improve the commu-nication between designers. The concepts and their rela-tionship through which a model of the system is expressedare precisely specified in a metamodel. However, to get agraphical representation of these models, two alternativesare possible: define a graphical view for each concept ofthe metamodel or extend UML in a profile to support theseconcepts. The former solution is relatively tedious due tothe need for a dedicated tool. The second solution aims toadd semantics to UML [8] in order to adapt it to a specificdomain and to use traditional modeling tools such as Mag-icDraw, Papyrus or RSA. MARTE (Modeling and Analy-sis of Real-Time and Embedded systems) [15] is a stan-dard proposal of the Object Management Group (OMG).The primary aim of MARTE is to add capabilities to UMLfor model-driven development of real-time and embeddedsystems. UML provides the framework into which neededconcepts are plugged. The MARTE profile enhances pos-sibility to model software, hardware and relations betweenthem. It also provides extensions to make performance andscheduling analysis and to take into account platform ser-vices (such as services provided by an operating system).
In this paper, we present our Gaspard2 design environ-ment dedicated to MPSoC allowing to move from the highlevel MARTE description to an executable platform. Gas-pard2 is based on Model-Driven Engineering [13] (MDE).This methodology revolves around two concepts: modeland transformation. Data and their structures are repre-sented in models, while the computation is done by transfor-mations. In our framework, models are used to represent thesystem (application, architecture, and allocation). Transfor-mations are employed to move from an abstract and con-templative model to a detailed and productive model. Theset of transformations forms the compilation chain. In our
23
case, this chain converts the platform-independent MPSoCmodel into a SystemC [11] code.
The rest of this paper is organized as follows. Anoverview of related work on the modeling of SoC and auto-matic generation of simulation out of it is provided in sec-tion 2. Section 3 introduces the MARTE profile for MPSoCmodeling and an overview of the extensions needed to tar-get a low level platform. The SystemC platform that we aretargeting is presented in details in section 4. Section 5 intro-duces the Gaspard2 environment for MPSoC design basedon a Model-Driven Engineering methodology. This paperfinishes with a case study illustrating the use of the modelsand the transformation in section 6 followed by a conclu-sion.
2. Related Work
Using UML standard for system design started in1999 [6]. At the beginning, this approach did not achievea great success due to the limited supporting tools and ca-pabilities to target executable platform. As an example, itis possible to quote the UML profile for SystemC based onUML 1.4 [4] dedicated to SoC modeling. In an attempt toresolve this issue, the Object Management Group (OMG)devoted significant efforts which yielded the MDE initia-tive. This methodology provides a set of guidelines fortranslating from platform-independent models to platform-specific models.
Several propositions based on UML were later made.Early propositions have focused on the model side of thisapproach. We can mention SysML [10], from whichMARTE has taken a certain number of concepts. It hasthe disadvantage of being too much generic, this means thatthere exist too many variation points to allow a completespecification of a system only at the model level. In the op-posite, the standardization proposal by Fujistu [9] about aUML profile for SoC tended to be too close from the imple-mentation, providing concepts very tied to SystemC. Noneof those works have investigated how to reach the imple-mentation from the specification.
More recently, there have been works also concernedby obtaining a realization out from the modeling of theSoCs, proposing model transformations. They highlightedthe need for model notation to have an entirely executablesemantics [7]. That is: not having any semantic variationpoints and containing information so that each part of thesystem can be completely realized. Unfortunately, so far thepropositions [7, 1, 14] have been limited as direct transfor-mations from UML profiles to SystemC simulations, takinglittle out of the powerful MDE approach.
In our project called Gaspard2 [16], we went further inthe usage of MDE by abstracting more the level of specifi-cation of the SoC and leveraging the model transformationsto target the multiple types of outputs that are needed duringthe SoC design.
3. The MARTE profile for MPSoC modeling
Before elaborating further on the generative side of ourtool, permitting the generation of the entire simulation ofthe system, we will present what can be considered by theSoC designer as the interface. This interface is composedof the concepts that the designer has to grasp and manip-ulate to express the complete SoC. The major part of theinterface is based on the MARTE profile. In the first partof this section we will articulate the advantages of MARTEfor this particular domain of application, and which majorconcepts of the profile we rely on. Later in this section wewill summarize the additional mechanisms Gaspard2 uses.
3.1. The MARTE profile as a base
The modeling of SoC in Gaspard2 is nearly entirelybased on the MARTE profile (and of course on UML). Oneof the main advantages of MARTE is that it clearly distin-guishes the hardware components from the software com-ponents. This is done via stereotypes provided by the De-tailed Resource Modeling (DRM) package, in particular theHwResource and SwResource stereotypes. For SoC concep-tion this separation is of prime importance as it is usual tocreate those two parts of the system simultaneously, by dif-ferent teams. Moreover, this separation provides a flexibleway to independently change the software part or the hard-ware part. For instance, this allows testing the software ondifferent kind of hardware architecture, or to reuse an archi-tecture (with little or no change) for different applications.
Compared to UML, with MARTE the hardware can bedescribed with much more precision. The architecture ofthe hardware is described in a structural way. The notionof component permits to reuse a set of basic components invarious places and to define the architecture hierarchically.In Gaspard2, only the HW_Logical sub-package is used. Itallows to describe information about the kind of availablecomponents (HwRAM, HwProcessor, HwASIC, HwBus. . . ),their characteristics, and how they are connected to eachother. In Gaspard2 no use is done of the HW_Physicalsub-package because when the system is entirely on onechip, synthesis tools can compute automatically an opti-mized layout.
Gaspard2 also leverages from the MARTE profile the Al-loc package. As hardware and software are modeled inde-pendently, concepts to express how to link them togetherare necessary. The Alloc package provides the required con-cepts to associate a task or a data onto a processor or a mem-ory. For now only the allocation of nature spacialDistribu-tion is handled by Gaspard2. This is so because the seman-tics of the application, which we will describe later in thissection, is simple enough so that a good scheduling is al-ways possible to determine statically (at compilation time).In future versions of Gaspard2, the nature timeSchedulingmight be taken into account. This would allow the SoC de-
24
signer to force a specific order of task execution or memoryallocation.
The last major part of MARTE on which Gaspard2 reliesis the Repetitive Structure Modeling (RSM) annex. Thispackage defines stereotypes and notations to describe in acompact way the regularity of a system’s structure or topol-ogy. The structures considered are composed of repetitionsof structural elements interconnected via a regular connec-tion pattern. It provides the designer a way to express mod-els efficiently and explicitly with a high number of iden-tical components. In Gaspard2, the concepts brought bythis package allow both to model concisely large regularhardware architectures, such as the more and more frequentmulti-processor architectures, and the parallel applications.A detailed description about its usage and about using itwith the allocation package can be found in [3].
The lower part of Figure 4 shows the model of the maincomponent of a hardware architecture. It is constituted of4 processing units (using the repetition concept), a RAM,a ROM, and a crossbar to interconnect those componentstogether. The MIPS-PU component is not stereotyped Hw-Processor because this component is composed of both aprocessor and a cache. The Reshape connectors permit tospecify which component is connected to which repetitionof the slave port of the crossbar.
The other packages of the MARTE profile are not takeninto account in the transformation chains of Gaspard2. Themain reason is that our tool focuses only on one kind of sys-tems, signal intensive processing applications on MPSoC,within the broad domain of systems that MARTE encom-passes. The SoC designer can still use those concepts themin his or her model in order to explicitly describe or specifythe system: they will simply be ignored by the transforma-tions.
3.2. Introduced extensions
In order to generate a complete implementation of themodel, a completely defined semantics and very precisedetails on the elementary component are necessary. AsMARTE strives to be generic, for its best, so that it can ac-commodate a large set of needs, some of the needed infor-mation required for the implementation is not expressibleonly with the concepts provided. Therefore Gaspard2 intro-duces additional concepts and semantics to fill up this needin the particular domain of SoC modeling. This is done viaa specific UML profile. This is a very good demonstrationof the advantage of the profiling mechanism of UML: it al-lows to use standard concepts understood by a large set ofpeople to model most of the system, and to introduce addi-tional, very precise, concepts for the specific domain that aparticular tool focuses on. We are presenting here the ma-jor two extensions introduced for the need of MPSoC auto-matic generation.
The first addition to MARTE concerns the semantics ofthe application modeling. In MARTE, as in UML, mostly
any kind of application can be specified but the behaviourof the application cannot be entirely defined, it is up to theprogrammers to code the precise behaviour of each compo-nent. In Gaspard2 we have restrained the domain of appli-cation which can be modeled to data-flow systematic appli-cations, which is one of the major domains of applicationencountered in the field of MPSoC. So, in addition to theMARTE stereotypes SwResource (for the application com-ponents) and FlowPort (for all the ports), the semantics in-troduces a particular Model of Computation (MoC) basedon ArrayOL [2]. This language permits to represent the ap-plication in a declarative way, well fitted to the graphicalrepresentation of UML, and is able to express all the dataand task parallelism of an application.
Figure 1. Deployment of a MIPS processor.The second extension of Gaspard2 over the MARTE pro-
file concerns the description of the elementary components:the components which are the basic blocks of all the othercomponents. To transform the high abstraction level modelsinto simulation code, very detailed deployment informationmust be provided. In particular, every elementary compo-nent must be linked to an existing code, for both the hard-ware and the application. A specificity of the SoC designis that one functionality can be implemented in differentways. This is necessary for testing the system with differenttools, or at different levels of abstraction, along the designphase. Moreover, this is also necessary to facilitate applica-tion component reuse on different hardwares: for instancean application component can optimized for a specific pro-cessor, or written as an hardware accelerator. Thereforewe have introduced the concept of AbstractImplementationwhich expresses one hardware or software functionality, in-dependently of the compilation target. It contains one orseveral Implementations, each one being used to define aspecific implementation at a given simulation level and pro-gramming language. Figure 1 shows an example of an Ab-
25
stractImplementation of a MIPS processor which containstwo Implementations at the CABA and PVT levels writtenin SystemC. The Implementation which fits best the targetwill be used to reify the component during the compilationphase. This automatic selection allows to generate the exactsame SoC model at different simulation levels. Addition-ally, the concept of CodeFile is used to specify the code andcompilation options required.
4. SystemC target platform
In our work, we focus on the use of Transaction LevelModeling (TLM) as a viable approach for accelerating MP-SoC simulation. In TLM, a set of abstraction levels sim-plifying the description of inter-module communication isdefined. The simulation time is reduced by augmentingcommunication operation granularity. Consequently, signalhandshaking, as used in cycle accurate level, is replaced inTLM by transactions using objects (i.e. words or frames)over communication channels.
In fact, TLM refers to a taxonomy of several abstrac-tion levels. Each level differs from the others in the degreeof functional or temporal details it expresses. In order to al-low reliable design exploration, the simulation generated byour framework is at the so called Programmer’s View (PV)level. In the PV level the hardware architecture is specifiedfor both processing and communication parts, and some ar-bitration of the communication infrastructure is applied. Atthis level, application tasks are compiled for the host ma-chine to benefit from high simulation speedup (avoiding theinstruction interpreter). For performance estimation, thislevel is annotated with timing specification (PVT).
5. Gaspard2 environment
The Gaspard2 environment uses model transformationsin order to implement the MPSoC compilation flow. Trans-formations can be chained: the output model of a trans-formation is used as the input of an other one. They areemployed to move from an abstract model to a more de-tailed model. Those intermediary models, respecting apre-defined metamodel, provide strongly documented “syn-chronization points” in the compilation flow. Consequently,each transformation is independent from the others (theyonly depend on the pre-defined metamodel). This organiza-tion facilitates the reuse of transformations while compilingtowards different simulation levels. Moreover the compi-lation flow must adapt easily to the evolutions of the fastevolving SoC domain. Being able to write transformationswith a declarative language increases their maintainabilityand simplifies their modification. The declarative approachspecifies that each transformation is separated into a set ofrules. Each rule is associated to an explicit set of input andoutput patterns. In Gaspard2, the engine we used to execute
the transformations is a framework which permits to have adeclarative structure using Java.
Our Gaspard2 environment, thanks to the MDE ap-proach, provides great flexibility on the compilation chain.Thus, designers can couple additional tools, or target dif-ferent platforms. For instance we have also carried out thegeneration of VHDL implementation on FPGA and of syn-chronous language code from the same chain (Fig. 2).
OpenMP
OpenMPFortran
SystemCTLM-PVT
Polyhedron
LoopSynchronous
SynchronousEquational
CodeMeta-model Model Transformation
Key
Gaspard
VHDL
RTL
UML/MARTE
Figure 2. The Gaspard2 transformation chain.
An overview of our compilation chain is available inFig. 2. The UML/MARTE model, which represents the highlevel MPSoC model is first directly converted to the domainspecific model (Gaspard). It is then transformed into thePolyhedron model, where the application is reshaped andsplit on the different processing units. This derived modelis then transformed into the Loop model, where the appli-cation is represented according to a traditional nested loopschema. While those transformations are shared, the latertransformations are specific to the simulation level targeted.They generate SystemC simulation code at the PVT level.
6. Use case
In order to give more concrete description on our usageof MARTE and also to validate our methodology and modeltransformations, we are providing here an example of MP-SoC modeling with MARTE and generation of SystemCsimulation. The modeled application is an H.263 [5] videoencoder. It aims at compressing a video stream originallyrepresented as a sequence of QCIF pictures (176× 144 pix-els in YCbCr format). Due to space restriction, we can notshow the entire model of the application, however interestedreaders can obtain a much more complete description of thisuse case in [12].
26
Figure 3 presents the model of the second and thirdlevels of hierarchy of this application. The H263Encodercomponent reads one picture decomposed in three parts(corresponding to the three ports lumin, cbin, crin) and,via Tilers, it links the processing of block of pixels tothe H263MacroBlock component. The result of the pro-cessing is then reassembled via other Tilers and providedas output. In order to process the whole video sequencethe H263Encoder is instantiated at the first level of theapplication with an infinite repetition. The componentH263MacroBlock is constituted of three sub-componentspipelined to process the picture through the three stages ofthe H.263 encoder algorithm.
Figure 3. The main application componentsof the H.263 encoder.
The hardware architecture which executes the applica-tion is a SoC with 4 MIPS processors and shared memory.Part of the model of this architecture is presented in Fig-ures 1 and 4. Using the allocation and distribution mecha-nisms of the MARTE profile the mapping of the applicationon the hardware architecture was specified. Figure 4 showsthe part of the model specifying the distribution of the 99 in-stances of H263MacroBlock onto the four MIPS processors.Informally explained, the distribution linearizes the 11×9instances and maps them on the array of processors via amodulo function. Consequently, 25 instances are assignedto each processor except the fourth one which receives only24 instances.
Every elementary component has been deployed on anAbstractImplementation which contains at least one imple-mentation in SystemC at the PVT level (for the hardwarecomponents) or one C or C++ implementation (for the soft-ware components).
Once the system has been entirely modeled, the UMLfile is exported and is used as input of the Gaspard2 toolchain. The user selects which compilation chain should beexecuted among the four available. All the transformationsare automatically executed, generating the various interme-diary models, until reaching the target implementation. Inthe screenshot on Figure 5, the left panel shows all the gen-erated models (UML, Gaspard2, Polyhedron, Loop, and theSystemC/PVT source code). On the right panel, the UML
Figure 4. Allocation of the main applicationcomponent on the processors.
Figure 5. The Gaspard2 environment.
model is represented by an inheritance tree, and a part ofthe simulation source code is listed.
The complete generation of the source code, its compila-tion and the execution of the simulation constitute the firstpart of the validation of our method. As the model is ex-pressed at a high level of abstraction, modification of thesystem can be very easily done. This allows the designer totest various configurations and find which one is the best.For instance, we have changed the number of processorsin the system. This consists in modifying two numbers inthe model: in the shape associated to the MIPS processorcomponent, and in the shape associated to the ports of thecrossbar component. Then the simulation source code is re-generated, and the simulation of the new configuration canbe executed.
In order to validate the simulation, we have also writtenmanually a simulation of the system at a lower level of ab-
27
4 8 12 16
0
10000000
20000000
30000000
40000000
50000000
60000000
PV
CABA
Number of processors
Ex
ecut
ion
tim
e (c
ycle
s)
Figure 6. Number of simulated cycles de-pending on the amount of processors, at thePVT and CABA abstraction levels.
straction (the so called Cycle-Accurate Byte-Accurate level,CABA). Figure 6 presents the number of simulated cyclesused for the encoding of one picture when the architecturehas 4, 8, 12, and 16 processors for the two levels of ab-straction. About 15% to 30% of under-estimation can benoted on the PVT simulation, but the relative order betweenthe configurations is respected. In particular, both simula-tions show that a 16-processor architecture is slower thana 8-processor one (this is due to the conflicts for accessingthe RAM). This confirms the correctness of the generatedsimulation.
7. Conclusions
In this paper we have presented the Gaspard2 chain gen-erating a SystemC simulation at a high level of abstractionfor an MPSoC model. In the Gaspard2 environment themodeling is based on the MARTE profile with some ex-tensions necessary to completely specify the system and re-move any semantic variation point. The compilation of thesystem into a simulator is done via a chain of model trans-formations. This work has been validated by the modelingof a H.263 encoder parallelized on a shared memory MP-SoC architecture. In particular we have highlighted the easeof exploring various configurations thanks to the high levelmodeling.
As perspective of this work, first of all it could be in-teresting to write another transformation chain, targeting aSystemC simulation at lower level of abstraction. A majorpart of this work should be feasible by reusing the currenttransformation chain. We are planning to extend the ap-plication semantics in order to be able to model a biggerdomain of application. Finally, we are also considering toautomatize the design-space exploration, using the result ofthe generated simulation to determine which part of the in-put model to modify, until the results are compliant with aset of requirements defined by the designer.
References
[1] M. Alanen, J. Lilius, I. Porres, D. Truscan, I. Oliver, andK. Sandstrom. Design method support for domain spe-cific soc design. In MBD-MOMPES ’06: Proceedingsof the Fourth Workshop on Model-Based Development ofComputer-Based Systems and Third International Workshopon Model-Based Methodologies for Pervasive and Embed-ded Software (MBD-MOMPES’06), pages 25–32, Washing-ton, DC, USA, 2006. IEEE Computer Society.
[2] P. Boulet. Array-OL revisited, multidimensional intensivesignal processing specification. Research Report RR-6113,INRIA, Feb. 2007.
[3] P. Boulet, P. Marquet, E. Piel, and J. Taillard. RepetitiveAllocation Modeling with MARTE. In Forum on specifi-cation and design languages (FDL’07), Barcelona, Spain,Sept. 2007. Invited Paper.
[4] F. Bruschi and D. Sciuto. SystemC based design flow start-ing from uml model. In Proceedings of ESCUG, 2002.
[5] G. Cote, B. Erol, M. Gallant, and F. Kossentini. H.263+:video coding at low bit rates. IEEE Trans. On Circuits AndSystems For Video Technology, Nov. 1998.
[6] G.Martin. UML and VCC. White paper, Cadence DesignSystems, 1999.
[7] K. D. Nguyen, Z. Sun, P. S. Thiagarajan, and W.-F. Wong.Model-driven soc design via executable uml to systemc. InRTSS ’04: Proceedings of the 25th IEEE International Real-Time Systems Symposium (RTSS’04), pages 459–468, Wash-ington, DC, USA, 2004. IEEE Computer Society.
[8] Object Management Group, Inc., editor. UML 2 Superstruc-ture (Available Specification). http://www.omg.org/cgi-bin/doc?ptc/2004-10-02, Oct. 2004.
[9] Object Management Group, Inc., editor. UML Exten-sion Profile for SoC RFC. http://www.omg.org/cgi-bin/doc?realtime/2005-03-01, Mar. 2005.
[10] Object Management Group, Inc., editor. Final AdoptedOMG SysML Specification. http://www.omg.org/cgi-bin/doc?ptc/06-0504, May 2006.
[11] Open SystemC Initiative. SystemC. http://www.systemc.org/.
[12] E. Piel. Ordonnancement de systèmes parallèles temps-réel, De la modélisation à la mise en œuvre par l’ingénieriedirigée par les modèles. Thèse de doctorat (PhD Thesis),Laboratoire d’informatique fondamentale de Lille, Univer-sité des sciences et technologies de Lille, France, Dec. 2007.
[13] Planet MDE. Model Driven Engineering, 2007. http://planetmde.org.
[14] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. Amodel-driven design environment for embedded systems. InDAC ’06: Proceedings of the 43rd annual conference onDesign automation, pages 915–918, New York, NY, USA,2006. ACM.
[15] L. Rioux, T. Saunier, S. Gerard, A. Radermacher, R. de Si-mone, T. Gautier, Y. Sorel, J. Forget, J.-L. Dekeyser, A. Cuc-curu, C. Dumoulin, and C. Andre. MARTE: A new profileRFP for the modeling and analysis of real-time embeddedsystems. In UML-SoC’05, DAC 2005 Workshop UML forSoC Design, Anaheim, CA, June 2005.
[16] WEST Team LIFL, Lille, France. Graphical array specifica-tion for parallel and distributed computing (GASPARD-2).http://www.lifl.fr/west/gaspard/, 2005.
28
Executable Models and Verification from MARTE and SysML: a ComparativeStudy of Code Generation Capabilities
Marcello Mura Amrit Panda Mauro PrevostiniUniversity of Lugano
ALaRI - Faculty of InformaticsVia Buffi 13, 6904 Lugano, Switzerland
[email protected], [email protected], [email protected]
Abstract
In this paper two well known UML profiles, namelySysML and MARTE are closely examined and compared.Both profiles are well suited for the description of embed-ded systems, although focusing on different aspects and cantherefore be considered as complementary. While SysMLtargets system engineering descriptions in a high level ofabstraction and provide diagrams for requirements specifi-cation, MARTE is tailored for systems in which Real Timeconstraints play a major role. Expressiveness of such pro-files and their matching with languages that represent thenext step in the development of Hardware/Software systemswill be the main subject of this work. A Wireless Sensor Net-work scenario is taken as a reference case study and usedto illustrate a practical application of MDA.
1 Introduction
Complexity of electronic systems is constantly increas-ing and this requires new powerful design strategies. As aresult, automatization of the design process, starting fromlightweight representations (e.g. UML [11]), is a well es-tabilished trend nowadays. This process - that is still inprogress - produced as major results the definition of pro-filing in modeling languages [7] and the formalization ofModel Driven Architectures [6]. UML2 has been createdwith the intention of adding new capabilities for large scalesystems and achieving great semantic accuracy and con-cepts consolidation. With UML2 it is possible to developvery sophisticated models and profiles for nearly any typeof system (hardware, software, middleware).In this paper we analyze two of such UML profiles,SysML [9] and MARTE [5]. SysML targets system engi-neering descriptions in a high level of abstraction and pro-vides diagrams for requirements specification. MARTE onthe other hand was developed to model Real Time Systems
and is thus mainly targets timing performances (e.g. WCETetc). In particular we show how they can be employed forthe automatic generation of executable code. We mainly tar-get generation of SystemC models, but it is possible to thinkabout other possibilities as well. In particular could repre-sent a main topic in the future the mapping into Promela soto be able both to model systems and to extract propertiesto be verified bySPINmodel-checker.Briefly, the paper is organized as follows. Related works areillustrated in Section 2. A summary of SysML and MARTEprofiles is provided in Section 3 and Section 4. In Section 5we describe the process of mapping system description toSystemC and its code generation. A simple case study con-cerning the modeling of a Wireless Sensor Network is illus-trated in Section 6. In Section 7 conclusions are drawn andfuture work is briefly outlined.
2 Related works
In this section we present the usage of UML combinedto SystemC and related works. To allow using UML forHW/SW co-design, [23] started to extend UML by a profilefor SystemC that allowed to express a SystemC model inUML. In there a consistent research effort on generation ofSystemC code starting from UML diagrams has been done(see e.g. [25], [21] and [22]). Also well known commercialsoftware products target similar issues. I-Logix StateMate[3] generates executable models starting from StateCharts,MATLAB Stateflow [4] does the same starting from a sim-ilar concurrent FSM formalism. In [14] the translation ofStateCharts into Hierarchical Finite State Machines (HF-SMs) is explored in order to build test cases for the corre-sponding VHDL realization. StateCharts formalism is alsovery appropriate for the formal validation of models. Inparticular, automatic translation intoPromela/SPIN, a lan-guage used for automatic Model Checking, was presented in[19], [20] and [16]; recently an interesting approach to this
129
problem was reported in [18]. A lot of work has been donein the field of embedded systems, but unfortunately a lot ofdesigners were focused on software design, that excludedhardware part of embedded systems. In [13] a specializationof UML is presented to express embedded real-time appli-cations in an abstract way. [12] defines an UML Profile forSystemC, but no code generation capabilities for behavioralinformation are considered. Another point of view and pro-posal was presented in [15], the authors provide an analysisabout the structural modeling concepts in UML 2.0, whichhas added structural information such as class and struc-tured class. A lot of tools are presented that encapsulate thepossibility of UML to SystemC code generations.
3 SysML
SysML is a modeling language for representing systemsand product architectures, as well as their behavior andstructure. It tries to adopt modeling techniques known fromsoftware development to systems engineering, and supportsthe specification, analysis, design, verification and valida-tion of a broad range of complex systems. SysML providesa structural element calledblock. Blocks can be used torepresent any type of components of the system, functional,physical, and human, etc. and are used withinBlock Defi-nition Diagrams, which aim to describe the structure of thesystem. The SysML Block Definition Diagram (BDD) isbased on UML Class Diagrams and UML Composite Struc-ture Diagrams. It is also used to represent the system de-composition using for example associations and composi-tion relationships.
3.1 Block Definition Diagram
The role of a BDD is to describe the relationships amongblocks, which are basic structural elements aiming at spec-ifying hierarchies and interconnections of the system to bemodeled. A block is specified by itsparts, andflow ports.Parts represent the physical components of the block whileflow ports represent the interfaces of the block, throughwhich the block communicates with other blocks. BDDscan also represent the decomposition of a block [17] in or-der to show by which kind of parts, including their features,a block is composed.
3.2 Internal Block Diagram
The SysML IBD allows the designer to refine the struc-tural aspect of the model. The IBD is the equivalent of thecomposite structure in UML. In the IBD, parts are the basicelements of the diagram and they are assembled to definehow they collaborate to realize the behavior of the block. Apart represents the usage of the corresponding block. The
most important aspect of the IBD is allowing the designerto refine the definition of the interaction between the usageof blocks by defining flow ports as follows:
• ports are parts available for connection from the out-side of the owning block;
• ports are typed by interfaces or blocks that define whatcan be exchanged through them;
• ports are connected using connectors that represent theuse of an association in the IBD.
Figure 1 shows how to represent the internal structure ofa block calledSoC1 by means of an IBD. The IBD cor-responds to a block decomposition wheremodule1 andmodule2 are connected each other throughin and outports, whilemodule2 is connected through aninout portto the outside of the corresponding blockSoC1.
<><>
ibd SoC1
module2module1
flowPort_1
flowPort_2
flowPort_3
Figure 1. Internal Block Diagram representingthe usage of parts within block SoC1
3.3 SysML ports
Two types of ports are available in SysML:
• standard portshandling requests and invocations ofservices with other blocks (basically the same conceptas in UML2);
• flow portswhich let blocks exchange flows of informa-tion.
Flow ports specify the interaction points among blocks andparts supporting the integration of behavior and structure.For standard ports, an interface class is used to list the ser-vices offered by the block. For flow ports, a flow specifica-tion is created to list the type of data that can flow throughthe port.
4 MARTE
MARTE profile [5] is an evolution of the Schedulabil-ity, Performance and Time (SPT) profile with the aim toupgrade this profile to UML2. It is made of various pack-ages: namely MARTE foundations, MARTE design model,MARTE analysis model and MARTE annexes. The profileis intended to be a fundamental tool in the design of real
230
time systems. Both modeling and analyzing concerns aretackled leading to a complete instrument to improve designphase.In this section we focus in particular on the Time modelingwhich is part of MARTE foundations package. It allowsthe designer to define time constraints and bind his systemto them. We focus on the granularity as well as abstrac-tion provided in the temporal domain by this profile. As faras generation of code is involved, this piece of the profileis particularly useful and is fully complementary to SysMLprofile as the timing aspect is not dealt with in this latterprofile.Time constraints, to which any system must stick to, rep-resent a fundamental analysis aspects and are necessary inorder to determine performance of any kind of system. Spe-cially in the case of real time systems, time is very crucialand the system must abide by the hard as well as soft timeconstraints. In MARTE there are two kinds of time: the log-ical time and the chronometric time. The chronometric timeconcerns with the time cardinality alone, whereas the log-ical time concerns the ordering and organization of eventswhich can again be synchronous or asynchronous. The spe-cialization of the logical time model for synchronous eventsis independently known as the synchronous time model. Forextreme real time applications the simultaneity of events oc-currence is taken care by the synchronous time model.The MARTE profile allows << Clocks >> whichare instances of<< ClockType >>. The <<modelLibrary >> TimeTypesLibrary of MARTE has theenumerations<< enumeration >> TimeNatureKind and<< enumeration >> TimeInterpretationKind. TimeNa-tureKind specifies whether the time is discrete or dense.In the first case time is seen as in a High Level HardwareDescription Language in which clock ticks are discrete andtime does not elapse during delta cycles. The second casematches the physical time that is known to be continuous.TimeInterpretationKind specifies whether time should beinterpreted as instant or as duration. Typically the instantand duration time interpretation kind refers to the time re-lated events that occur in a particular instant called instanttime events or occur over some period of time called dura-tion time events. The<< stereotype >> ClockType givesthe attributes that any clock can take. The units of time thatare supported by MARTE<< modelLibrary >> TimeLi-brary are defined based on a base time and a conversion fac-tor. The specifications of the clock objects can be obtainedfrom << ClockConstraint >> and the scheduling ofthe clocked events from the<< TimedConstraints >>.The << timedDomain >> encapsulates a certain num-ber of events with their clocks and triggers.
5 Mapping to SystemC
Automatic code generation is a fundamental objectivewhen dealing with design of complex systems. On one handit speeds up development time, on the other extensive test-ing is possible from the early development stages thereforeimproving quality and reliability of final products. Choiceof the starting and target formalisms are the main issues insuch process. In fact they have a major impact on expres-siveness and performance of the generated code that are themajor concerns in such an effort. UML represents a con-vincing starting point as it is the most widely used plat-form independent modeling language. It contains possibil-ity of conveying both structural and behavioral information,moreover its expressiveness can be enriched by profiling. Inparticular subset of the language or of its profiles can con-tain useful information for the generation phase as will beshown later. SystemC [10] represents a convenient choiceas target formalism. It can be used to bridge high level spec-ifications (normally expressed in languages as C or throughscripts in an environment like Matlab) with actual imple-mentation of Hardware systems (normally described in lan-guages such as Verilog or VHDL). SystemC is a class oflibraries built on top of C++ that add to such language a sim-ulation framework, a conceptual representation of time andHardware oriented datatypes. For this reason it represents avalid option for prototyping and early design phases but canalso be employed for later phases up to syntesis. There ex-ist commercial tools for generating Hardware starting fromSystemC representations (e.g. Cynthesizer [2]) and transla-tion of SystemC into synthesizable VHDL or Verilog is notknown to be an untractable problem.
5.1 Code Generation
The process of code generation happens in two steps asin a Software Compiler. Starting from information exportedin textual format from the UML tools (i.e. xmi or di2) an in-termediate representation is built. Then code is built startingfrom such a representation. In this way it is possible to ex-tend the reuse of both parts. Changing the UML tool (and asa consequence the source XMI dialect) reflects only in ap-plying changes to the frontend reusing the existing backend.In case different target formalisms are used the frontend partcan be reused and only the backend needs to be modified.
5.2 Translation Template
In order to define how high level UML specifications aretranslated into SystemC code it is necessary to define a tem-plate code. Ideally there is a one to one mapping betweenUML (also involving stereotypes coming from profiles) andtransformations can be performed in both directions using
331
such mapping. In practice realization of such mapping isnot straightforward. While it is possible to profile UMLin a way that all the SystemC building blocks can be rep-resented (see e.g. [24]) it is not straightforward to createa consistent UML model starting from representation of agiven SystemC code. Limits on the style of coding mustbe imposed so that behavioral information can be conveyedinto appropriate state diagrams.
5.2.1 SysML models
We will start by defining basic SystemC entities likemod-ule, port andprocess. The mapping between SysML andSystemC items is defined as follows:
• SysMLpartsmapped to SystemCmodules;
• SysMLflow portmapped to SystemCports;
• SysMLallocationsmapped to SystemCprocesses.
Now we are able to firstly create a header file (.h) for eachmodule that must include:moduledefinition;port declara-tion; processdeclaration. The header files ofmodule1 andmodule2 of SoC1 described in Figure 1 can be translatedinto SystemC code as follows:
SC_MODULE (module_1) {
public:sc_out <int> flowPort_1: type;sc_in <int> flowPort_2: type;
SC_CTOR (module_1){
SC_THREAD(verifyValue);}
void verifyValue();};
SC_MODULE (module_2) {
public:sc_in <int> flowPort_1: type;sc_out <int> flowPort_2: type;sc_inout <int> flowPort_3: type;
SC_CTOR (module_2){
SC_THREAD(getValue);SC_THREAD(increaseValue);
}
void getValue();void increaseValue();
};
Secondly we can build the implementation files (.cpp) thatdescribes the module behavior and could be implementedstarting from StateCharts diagrams as described in our pre-vious [21].
5.2.2 MARTE models
The main limitation we encountered with SysML is the lackof constructs for modelling time. Thus we were pushedto examining different packages and model libraries in theMARTE time profile and try to find a mapping into Sys-temC. This way increasing the expressiveness of the mod-elling formalism by the concurrent use of multiple profileswe improve the automatic generation phase.Discrete time can be mapped in SystemC to any digitalclock object with a defined period and duty cycle and alsothe unit of time but it fails to map the dense time to any kindof clock. In fact being SystemC a high level programminglanguage the representation of dense time in non-discretedomain is not feasible.The chronometric time model can be considered as directlymapped to SystemC simulation time that expresses the timecardinality. Logical time can be represented by means of thesensitivity list of any process of the system. Since the ideabehind the notion of logical time is the ordering of events ina sequence, we take the advantage of the execution of pro-cesses on triggering of certain events. For example if wewant to order the execution of events A, B and C in the or-der C follows B follows A. And the only criterion for theirexecution is following the preceding event.These events are mapped to processes in SystemC namelyproc a, proc b, andproc c. We make these processes sen-sitive to only a single signal saytrig a, trig b andtrig c re-spectively. The state oftrig b is changed only at the end ofproc a. Process A may include the modifications of one ormany signals but we need to make sure that the last changethat the process makes is that oftrig b which triggers theexecution ofproc b. Similarly proc b should also changestate oftrig c at its end to triggerproc c. This assures theordered execution of the processes. We trigger the first pro-cess (A) in the main control unit by changing the state oftrig a. There may be a case when the criteria for executionof a process may not be following the preceding event alone.In such case the additional signals to which the process issensitive are moved from the sensitivity list of each processand appended to the sensitivity list of the first process (inthis caseproc a).The SystemCwait (duration, unit)function can be used toregulate the time constraint equations. For example if a spe-cific event is expected to occur within a particular durationof time after a preceding event , we can wait for that amountof time and then poll for the completion of the event. If thepoll fails then the constraint is no longer valid and system
432
gives up in performance. Thewait () should be invokedat the end of the preceding process (in the control unit ofthe system) and flow should be directed to polling the nextevent. Similar visualization in SystemC is achieved by theclock object which is an object of the classsc clock.Mapping sc time unit (SCFS; SCPS; SCNS; SCUS;SCMS; SCSEC) to the TimeLibrary, we can design anyspecific clock with any time unit. As long as the TimeInter-pretationKind is involved the mapping s as follows:
• Duration is mapped to a scheduler,started withsc start(double d, sctime unit t) and executing a sequence ofoperations which cannot be accomplished with a singleinstruction in an instant. It takes more than one clockcycle to complete the job.
• Instant is mapped to the processes that are involved insignal modifications or initializing a scheduler as thisis done only with one instruction in an instant. It takesonly one clock cycle to complete job.
6 Case Study
This section discusses a case study with the aim topresent the general rules described in this paper and applythem to aSensorNode within a Wireless Sensor Network(WSN) system. Figure 2 shows the IBD of a Sensor Nodedescribing its internal structure. As we can see our systemis composed ofCPU , Sensor, Actuator, RF transceiver,andMemory. When switched on, the Sensor measures theexternal temperature and sends the value to the CPU to beelaborated. If a predefined threshold is overflown, the CPUtells the Actuator to perform the appropriated action, other-wise it stores the data in the Memory. If the Memory is full,the CPU sends the data to another sensor through its RFtransceiver and then goes to the Idle state waiting for thenext measurement to be performed. Given SysML diagram
ibd SensorNode
RF
CPU
Sensor
ActuatorMemory
<> <> <>
<> <>
<>dataExchange
data
dataStored actionDecided action
measuredTemp extTemp
Figure 2. Internal Block Diagram of the SensorNode
in Figure 2 the following SystemC code will be generated:
SC_MODULE(CPU) {public
sc_in <float> measuredTemp:Temperature;sc_inout <float> data:Info;sc_inout <float> dataStored:Info;sc_out <bool> actionDecided:Impulse;
SC_CTOR(CPU){
SC_THREAD(elaborate);SC_THREAD(store);
}void elaborate()void store()
};
SC_MODULE(Sensor) {public
sc_in <float> extTemp:Temperature;sc_out <float> measuredTemp:Temperature;
SC_CTOR(Sensor){
SC_THREAD(measure);}
void measure()};SC_MODULE(Actuator) {
publicsc_in <bool> actionDecided: Impulse;sc_out <bool> action: Impulse;
SC_CTOR(Actuator){
SC_THREAD(performAction);}
void performAction()};
SC_MODULE(RF) {public
sc_inout <float> dataExchange: Info;sc_inout <float> data: Info;SC_CTOR(RF)
{SC_THREAD(send);
}void send()
};
As it is easy to notice no information on timings (i.e. clocksof the system) is available. For this reason we used the pre-viously described mapping of the MARTE time profile. Asa simplification we use a single clock for the whole systemthat defines the timescale of the simulation. In practice it ispossible to have multiple clocks in the various blocks.
533
The classes sketched in Figure 3 allow defining a clock for
<< clockType >> { nature=discrete, isLogical=false, unitType=ns } TIMECLK
period: Integer
<< clock >> { unit= ns } clk1:TIMECLK period=10
<< TimedDomain >> Clocks
Figure 3. MARTE representation of a 100MHzClock
the whole system. In particular the information containedin such figure can be translated in SystemC in the statementsc clock(clk1,10,SCNS,0.5). It is straightforward to insertin the classes more information (e.g. duty cycle) and reusethem for generation of code.
7 Conclusions
In this paper we investigated how enrichment comingfrom UML profiles can be used in order to enhance codegeneration techniques. We closely analyzed both SysMLand MARTE profiles and found that even though the formerlooks better suited for generating SystemC code, interest-ing possibilities can be enabled also by the latter. In partic-ular we noticed that contemporary use of stereotypes fromboth profiles may represent an interesting option. We foundthat tool support for such operation is still to be improved.Some tools (i.e. Rhapsody [1]) do not support MARTE pro-file. On the other hand Papyrus [8], supporting both profilesthrough plugins, has some major limitations in the availablefeatures (i.e. missing diagrams, limited xmi translation).Future work will involve refinement of obtained results andapplication of similar techniques for validation of systems.Analysis of existing UML tools and possibly extensions areforeseen.
Acknowledgements
The authors would like to thank Luis Gabriel Murillo forhis precious help.
References
[1] http://modeling.telelogic.com/products/rhapsody/index.cfm.[2] http://www.ForteDS.com.[3] http://www.ilogix.com/sublevel.aspx?id=74.[4] http://www.mathworks.com/products/stateflow/.[5] http://www.omgmarte.org/.[6] http://www.omg.org/mda/.[7] http://www.omg.org/technology/documents/profilecatalog.htm.[8] http://www.papyrusuml.org.[9] http://www.sysml.org.
[10] http://www.systemc.org.[11] UML: The unified modeling language - standard, version
2.0, Aug. 2005.[12] F. Bruschi and D. Sciuto.A SystemC based Design Flow
starting from UML Model. In Proc. of ESCUG ’02, 2002.[13] R. Chen, M. Sgroi, L. Lavagno, A. Vincentelli, and
J. Rabaey.UML And Platform Based Design. In UML forReal Design of Real-Time System, Kluwer Academic Pub-lisher, 2003.
[14] F. Fummi, M. Sami, and F. Tartarini. Use of Statecharts-Related description to achieve testable design of control sub-systems. InProc. GLSVLSI, 1997.
[15] S. Gerard and F. Terrier.UML for Real-Time In UML forReal design of Real-Time System. Kluwer Academic Pub-lisher, 2003.
[16] S. Gnesi, D. Latella, and M. Massink. Modular semanticsfor a UML statechart diagrams kernel and its extension tomulticharts and branching time model-checking.Journal ofFormal Aspects of Computing, 51, 2002.
[17] M. Hause and A. Moore.The Systems Modeling Language- A paper presentation from ARTiSAN Software Tools. AR-TiSAN Software Tools, 2006.
[18] D. Latella, I. Majzik, and M. Massink. Automatic verifi-cation of a behavioural subset of UML statechart diagramsusing the spin model-checker.Journal of Logic and Alge-braic Programming, 11, 1999.
[19] J. Lilius and I. P. Paltor. vUML: A tool for verifying UMLmodels.ase.
[20] E. Mikk, Y. Lakhnech, M. Siegel, and G. J. Holzmann.Implementing statecharts in promela/spin. InProc. WIFT,1998.
[21] M. Mura and M. Paolieri. Sc2: State charts to system c:Automatic executable models generation. InproceedingsFDL07, Barcelona, Spain.
[22] K. D. Nguyen, Z. Sun, P. Thiagarajan, and W. Wong. Model-driven SoC design via executable UML to SystemC. InProc.of RTSS.
[23] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio.AnHW/SW Co-design Environment based on UML and Sys-temC. In Proc. of Forum on specification and Design Lan-guages, FDL’05, 2005.
[24] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. A socdesign methodology involving a uml 2.0 profile for systemc.In Proc. DATE, 2005.
[25] C. Xi, L. JianHua, Z. ZuCheng, and S. YaoHui. ModelingSystemC design in UML and automatic code generation. InProceedings of ASP-DAC, 2005.
634
Modeling SPIRIT IP-XACT with UML MARTE
Charles Andre†, Frederic Mallet†∗, Aamir Mehmood Khan∗, Robert de Simone∗
AOSTE Project, I3S/INRIAINRIA Sophia-Antipolis Mediterranee.∗
Universite de Nice-Sophia Antipolis, France.†
{Charles.Andre, Frederic.Mallet, Aamir.Mehmood, Robert.De Simone}@sophia.inria.fr
Abstract
Large System-on-Chips (SOC) are now built by assem-bly of existing components, modeled at different represen-tation levels(TLM, RTL . . . ). The IP-XACT standard wasrecently developed to help normalize interfaces of IP com-ponents, and ease their composition. Currently it does notfully face timing representation issues. The equally recentMARTE UML profile focuses explicitly on the rich expressionof time (physical or logical), clocks, and timing features.
We attempt here to embed SPIRIT IP-XACT representa-tions as MARTE models. This leaves open the possibility toextend the formalism with timing aspects, while it providesgraphical editing functionalities and a way to experimenton extensions.
1. Introduction
Reuse and integration of heterogeneous IntellectualProperty (IP) from multiple vendors is a major issue ofSystem-on-Chip (SoC) design. Existing tools attempt tovalidate assembled designs by global co-simulation at theimplementation level. This fails more and more due to theincreasing complexity and size of actual SoCs. Thus, thereis a clear demand for a multi-level description of SoC, withverification, analysis and optimization possibly conductedat the various modeling levels. In particular, analysis ofgeneral platform partitioning based on coarse (extra func-tional) abstraction of IP components is highly looked after.This requires interoperability of IP components describedat the corresponding stages, and the use of traceability toswitch between different abstraction layers. Although this ispartially promoted by emerging standards, it is still insuffi-ciently supported by current methodologies. Such standardsinclude OCSI SystemC, SPIRIT Consortium IP-XACT, Sil-icon Integration Initiative OpenAccess API, and also recentUnified Modeling Language [1] (UML)-based standards likethe UML Profile for Modeling and Analysis of Real-Time
and Embedded systems (MARTE [2]) that specifically tar-gets real-time and embedded systems.
System Modeling requires representation of bothstructural/architectural/platform aspects at differentlevels of abstraction and behavioral/functional as-pects possibly considering timing viewpoints such asuntimed/asynchronous/causal, logical synchronous/cycle-accurate or physical/timing models. Semantics providesbehavioral meaning to full systems from the combinationof the behavior of its components. For system structure rep-resentation, UML uses component and composite structurediagrams, while SYSML [3] uses block diagrams. Toolslike Esterel Studio, and virtual platforms like CoWare, Syn-opsys CoreAssembler and ARM RealView, introduce theirown architecture diagrams. IP-XACT provides some ADL(Architecture Description Language) features for externallyvisible common interfaces and recognized state encodings,together with administrative information (ownership, toolchains, versioning ...). It uses its own XML syntax, forspecification of IP meta-data and tool interfaces.
For component behavior representation, SystemC pro-vides programming libraries to represent IP componentbehavior at different abstraction levels, from TransactionLevel Modeling (TLM) to RTL but it requires additionalsupport for architecture modeling. IP-XACT relies on Sys-temC, VHDL, and Verilog HDL to specify the actual be-havior of components. UML behavioral diagrams provide asupport for describing “untimed” algorithms, while MARTEalso provides support for logically or physically timed be-haviors. Generally speaking, the behavioral models in UMLare more abstract than commonly used SystemC levels,such as TLM/PV, TLM/CC, or RTL. In fact, state, sequenceand activity diagrams can be thought as closest to TLM/CP(Communicating Processes) models, which are still seldomused in SystemC methods. Then MARTE could be seen asintroducing the relevant timed version at this level (like PVTdoes for PV), through logical time and abstract user-definedclock threads.
One good feature of UML is its extendability, with the
35
profiling mechanism. On the other hand the set of consid-ered features should be as much as possible standardizedand agreed upon (if to allow interoperability), which is themain goal of the SPIRIT consortium. Therefore a UML pro-filing approach for IP-XACT based on relevant metamodelswould allow easy creation and extension of model editorsfor IP-XACT as the standard evolves, as well as experimen-tations with prototypal versions. Models can then be trans-lated into IP-XACT syntax for tool integration. We choseto do this by specializing the MARTE profile, which alreadyprovides a number of modeling features for extra-functionalaspects (such as logical timing elements).
So our work goes in two steps: first we create an ad-hocUML profile for IP-XACT, then we study how a proper sub-set of MARTE can be used to add modeling expressivity fortimed behaviors. The resulting profile should be upload-able into existing graphical tools (e.g., Eclipse UML, Mag-icDraw by NoMagic, Rational Software Architect by IBM,Artisan).
This paper presents the details of our metamodeling(Section 2) and profiling (Section 4) of IP-XACT in UMLreusing MARTE wherever possible. In Section 3, we givean overview of the aspects reused from MARTE: the sub-profiles for Generic Resource Modeling (GRM) and Hard-ware Resource Modeling (HRM) for the structural aspects,the TIME subprofile to provide abstract behavioral aspectsof IPs and the ALLOCATION subprofile for their mappingonto the virtual platform itself. As a running example, weuse the IP-XACT specification of the Leon2 processor, re-leases as part of the IP-XACT 1.4 RC1 distribution package(http://www.spiritconsortium.org).
Related work: UML profile dedicated to SOC mod-eling have been proposed, such as UML4SOC [4] andUML4SYSTEMC [5], but they do not consider timing as-pects. UML/SYSML have also been proposed as repre-sentation formalisms to support analysis and produce Sys-temC outputs [6]. The yearly DAC satellite workshopUML for SOC design deals with these issues (http://www.c-lab.de/uml-soc).
2. SPIRIT IP-XACT metamodel
IP-XACT defines seven kinds of models: Component,Bus definition, Abstraction definition, Design, Abstractor,Generator chain, Configuration. We consider only the firstfour.
2.1. Component
Component is the basic model element in SPIRIT. EveryIP is described as a component without distinction of type,whether they represent computation cores (processors, co-processors, DSPs), peripheral devices (DMA controllers,
timers, UART), storages (memories and caches), or inter-connects (simple buses, multi-layer buses, cross bars, net-works on chip).
Figure 1 shows the main features of components as con-sidered in IP-XACT, their interface and their memory hierar-chy. A component identifier is unique, it specifies its name,the containing library, the vendor and the version number. Atextual description may comment its intended role. A com-ponent also contains a precise description of the memoryhierarchy: addressSpaces and memory mappings.
Figure 1. IP-XACT Component metamodel.
The hardware model of a component describes its phys-ical ports, the different views available (RTL, TLM, docu-mentation) and a set of parameters.
The view mechanism is a provision for having severalmodels of the same component at different levels of abstrac-tion. The ports can be wire ports (for RTL) or transactional(for TLM) ports. The formers only allows purely binaryvalues or vectors of binary values.
BusInterface allows for grouping together ports that col-laborate to a single protocol. Components communicatewith each other through their bus interfaces tailored for aspecific bus. The bus interfaces map the physical ports ofthe component to the logical ports of the abstraction defi-nition. They also identify the interface mode (master, mir-rored master, slave, mirrored slave). The mirroring mecha-nism guarantees that an output port of a given type is con-nected to an input port of a compatible type.
Channels describe multi-point connections betweencomponents when the interfaces are not directly compati-ble and require some adaptation.
2.2. Abstraction and Bus Definition
A BusDefinition describes the high-level attributes of theinterfaces connected to a bus. For instance, it defines a max-imum number of masters and slaves, and whether a masterinterface can be directly connected to a slave interface orshould rather go through mirrored master/slave interfaces.A bus definition can extend another bus definition, thusallowing the definition of compatibility rules with legacy
36
buses. For instance the AHB (Advanced High-performanceBus) definition extends the AHBlite definition. When ex-tending another bus definition, some constraints must beenforced. For instance, an extending bus definition mustnot declare more masters and slaves than the extended one.
An AbstractionDefinition gives lower-level attributes fora given BusDefinition. There can be several abstractiondefinitions for the same bus definition, like AHB rtl andAHB tlm. In the same way, an abstraction definition can ex-tend another one with also some compatibility constraints toenforce. The abstraction definition defines the ports, whichhave to be defined by the bus interfaces, and constrains them(type, direction . . . ).
Figure 2. IP-XACT BusDefinition metamodel.
2.3. Design
A Design represents a system or a sub-system, it de-fines a set of component instances and their interconnec-tions. Ad-hoc connections connect two ports directly, wireports but also transactional ports, without using a bus in-terface. Interconnections are point-to-point connections ofbus interfaces from two siblings components, whereas hier-archical connections connect components at different hier-archical levels (e.g., a parent to one of its children).
3. The UML MARTE Profile
3.1. General overview
The new OMG UML profile for MARTE supersedes andextends the former UML profile for Schedulability, Perfor-mance and Time (SPT[7]). MARTE adresses new require-ments: specification of both software and hardware modelaspects; separated abstract models of applications and exe-cution platforms; modeling of allocation of the former ontothe latter; modeling of large domains of Time and Non-Functional properties.
MARTE consists of three packages. The first package de-fines the foundational concepts used in the real-time and
Figure 3. IP-XACT Design metamodel.
embedded domain. These foundational concepts are refinedin two other packages to respectively support modeling andanalysis concerns of real-time embedded systems.
The second package addresses model-based design. Itprovides high-level model constructs to depict real-timeembedded features of applications, but also detailed soft-ware and hardware execution platforms.
The third package addresses model-based analysis. Itprovides a generic basis for quantitative analysis sub-domains.
3.2. Highlights of MARTE parts relevant toIP-XACT profiling
Our profile for SPIRIT reuses several model elementsfrom the first and second packages. This subsection brieflydescribes these borrowings.
The central concept of resource is introduced in theGeneric Resource Modeling (GRM) package of MARTE. Aresource represents a physically or logically persistent en-tity that offers one or more services. A Resource is a classi-fier endowed with behavior (a BehavioredClassifier in UMLterminology), while a ResourceService is a behavior. Re-source and ResourceService are types of their respectiveinstance models.
Several kinds of resources are proposed in MARTElike ComputingResource, StorageResource, Communica-tionResource, TimingResource. Two special kinds of com-munication resource are defined: CommunicationMedia andCommunicationEndPoint. The communication endpointacts as a terminal for connecting to a communication media;typical associated services are data sending and receiving.
For structural modeling, MARTE enriches the conceptsdefined in the UML composite structures. StructuredCom-ponent defines a self-contained entity of a system, which
37
may encapsulate structured data and behavior. An inter-action port is an explicit interaction point through whichcomponents may be connected. There exist two kinds ofports: MessagePort and FlowPort. MessagePort supportsa request/reply communication paradigm, whereas Flow-Port enables flow-oriented communication paradigm be-tween components. Thus, MARTE supports both messageand flow oriented communication schemas.
The MARTE Allocation associates functional applicationelements with the available resources (the execution plat-form). This comprises both spatial distribution and tempo-ral scheduling aspects, in order to map various algorithmicoperations onto available computing and communication re-sources and services.
Both Resource and Allocation refer to Time. In MARTE,Time can be chronometric (refering to physical time) or log-ical. The time model is defined in the Time package ofMARTE and it supports concepts as timed events, timed be-haviors, timed values. Details about the MARTE Time andAllocation models are presented in a previous paper[8].
The Detailed Resource Modeling (DRM) package ofMARTE specializes these concepts. It consists of two sub-packages: Software Resource Modeling (SRM) and Hard-ware Resource Modeling (HRM). Only the latter is usedand described in the following.
Figure 4. MARTE hardware resource meta-model.
As shown in Figure 4, HW Resource (HW Re-sourceService, resp.) specializes Resource (Resource-Service, resp.) defined in the GRM package. A hard-ware resource provides at least one resource service (hencethe prefix ‘p ’ in the role name) and may require (‘r ’prefix) some services from other resources. Note that aHW Resource can be hierarchical. The HRM package isfurther decomposed in two sub-packages: HW Logical andHW Physical. The former provides a functional classifica-tion of hardware entities, the latter defines a set of activeprocessing resources used in execution platform modelingand close to several SPIRIT concepts.
HW Resource are specialized in the same way as thegeneric resources of the GRM package. Figure 5 is an ex-cerpt of the GRM class hierarchy.
Figure 5. MARTE HRM metamodel.
4. Our UML profile for SPIRIT IP-XACT
Our UML profile for IP-XACT is defined by mapping theIP-XACT concepts identified in the metamodel (see Sec-tion 2) to UML metaclasses. Following B. Selic [9], wehave tried to define stereotypes with parsimony and to cre-ate new ones when no equivalent concepts were available inUML or in MARTE. In addition to the stereotypes we havealso defined a model library to provide a set of data typesequivalent to IP-XACT primitive types.
In Section 4.1 we describe our mapping of the IP-XACTconcepts to the UML world. In Section 4.2 we study how aproper subset of MARTE can be used to add modeling capa-bility for timed behavior.
4.1 Structural description
As we have seen in Section 2, there are two phases in thedefinition of an IP-XACT model. During the first phase, thecomponents and the buses are defined. The second phaseintegrates component instances into a design and specifiesthe interconnections. Contrary to other approaches that usecomponent diagrams for both phases we recommend the useof class/component diagrams for the first phase and the useof composite structure diagrams for the integration phase.Our approach eases the reuse of already defined compo-nents and allows for having several parts (component in-stances) of the same classifier without corrupting the classi-fier itself. This also results in very simple composite struc-ture diagrams while maintaining all the detailed informationon the classes themselves. Figure 6 shows a partial compos-ite structure diagram of the Leon2 design. The Leon2 pro-cessor is connected to a memory through a AHB-bus compo-nent. The connector hides the bus definition and interfaces.
Figure 7 represents the first phase with a detailed view ofthese components and buses along with an expanded viewof the bus interfaces connected to the ports.
In the following we describe our mapping of IP-XACTconcepts to UML keywords. These mapping rules, summa-rized in Table 1, allowed the automatic generation of IP-
38
Figure 6. The Leon2 design in UML.
XACT from the UML model of the Leon2 processor. Themodel transformation was performed using an XSLT (eX-tensible Stylesheet Language Transformation) description.
SPIRIT IP-XACT UML
Component «hwResource»VLNV VersionedIdentifierCPU «hwProcessor»Port «wirePort», «transactionalPort»Bridge «hwBridge»Clock Driver «hwClock»Timing Constraints Model LibraryBus Definition «busDefinition»Abstraction Definition «abstractionDefinition»Bus Interface «busInterface»Bus Interface Mode InterfaceModeKindDesign Composite StructureComponent Instance PartConnection Connector
Table 1. Mapping IP-XACT concepts to UML
4.1.1 Component
To distinguish hardware components (which must be trans-formed into IP-XACT components) from software compo-nents, we use the MARTE HwResource stererotype and itsspecializations. IP-XACT considers all IPs equally withoutdistinction of type, however, existing MARTE models us-
Figure 7. Component and bus definitions inUML.
ing specialized stereotypes (like HwProcessor) can also betransformed into IP-XACT components.
IP-XACT objects are uniquely identified by their identi-fier VLNV (Version, Library, Name, Vendor). Our modellibrary introduces a custom data type called VersionedIden-tifier to represent these identifiers.
Components use ports to interact with the communica-tion media. UML ports are extended by the MARTE HwEnd-Point stereotype. We further specialize this stereotype withtwo new stereotypes WirePort and TransactionalPort to addIP-XACT specific features, like the direction and width.
In components, bus interfaces map physical ports ofthe component to logical ports of an abstraction definition.Such a mechanism does not exist in MARTE, so we extendthe UML Interface metaclass with a stereotype called BusIn-terface to represent this concept. Master ports usually ini-tiate the transactions, thus they require services from othercomponents. In our profile, interfaces associated with themaster ports are represented as sockets, a usage dependencyin UML. Figure 7 shows an example with the initor port ofthe leon2Proc PV component. Interfaces associated withslave ports are represented as balls (a realization depen-dency in UML), since slave ports provide services to othercomponents. In Figure 7, the target port of the ahbram PVcomponent is such an example. The stereotype BusInterfacerefers to a BusDefinition and an AbstractionDefinition withits properties busType and abstractionType. It also has anenumeration literal to set its mode (master, slave or system)and a Boolean property to identify whether it is a direct or amirrored interface. The enumeration InterfaceModeKind isdefined in our model library.
We reuse the MARTE stereotype HwBridge to representIP-XACT bridges. Finally, the port clock drivers are mod-eled with the MARTE stereotype HwClock.
39
4.1.2 Bus and Abstraction Definition
There is no equivalent neither in UML nor in MARTE forthe IP-XACT important concepts of BusDefinition and Ab-stractionDefinition. Our profile introduces two stereotypesfor this purpose. Figure 7 illustrates that with the exampleof the BusDefinition ahb.
When a BusDefinition (or an AbstractionDefinition) ex-tends another one, this extension is modeled by the MARTERefinement mechanism. MARTE refinement is very similarto UML refinement but makes explicit the constraints im-plied by the refinement. We can use these constraints tospecify the IP-XACT compatibility constraints, for instance.
4.1.3 Design
The design component represents a system or a subsystem.It contains component instances and interconnects them.No additional stereotypes are required for this level. We rec-ommend the use of structured classifiers (UML hierarchicalclassifiers) with a composite structure diagram. The compo-nent instances become the parts of the structured classifier,both the interconnections and the ad-hoc connections aremodeled as UML connectors. The hierarchical interconnec-tions are represented with a delegate dependency betweenthe port of the parent and one port of one the children.
4.2 Behavioral description
Neither IP-XACT nor SYSTEMC provide any support tomodel at an abstraction level higher than SYSTEMC PV(Programmer View). However, combining UML state ma-chines and activities with the MARTE time model gives theopportunity to make models at a timed CP (Communicat-ing Processes) level. Figure 8 shows a timed activity thatdescribes a timer at a much higher level than the equivalentPV description, not to mention the RTL description. Us-ing such activities or SYNCCHARTS [10] (the synchronousversion of UML state machines) enables formal validationof composite models at the system level and gives a goldentimed model from which lower level descriptions can be de-rived or at least compared.
Figure 8. Timed Activity.
5 Conclusions
We have demonstrated how the UML MARTE could beused to represent the various IP-XACT features. We focusedon four top-level elements, but plan to extend it to the fullIP-XACT standard. The main interest of this work in ourview is that it allows the of MARTE for possible extensionsof IP-XACT with timing representations.
References
[1] Object Management Group. Unified Modeling Lan-guage Superstructure, V2.1.2. OMG Available Spec-ification, November 2007. OMG document number:ptc/2007-11-02.
[2] OMG. A UML profile for MARTE. OMG AdoptedSpecification, August 2007. OMG document number:ptc/07-08-04.
[3] OMG. Systems Modeling Language (SysML) v1.0.OMG Available Specification, September 2007. OMGdocument number: formal/2007-09-01.
[4] OMG. UML profile for System on a Chip v1.0.1. OMGAvailable Specification, August 2006. OMG documentnumber: formal/06-08-01.
[5] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. ASoC Design Methodology Involving a UML 2.0 Profilefor SystemC. In Proc. of the Conf. on Design, Automa-tion and Test in Europe (DATE), March 2005, Munich,Germany. IEEE, pages 705–709.
[6] A. Viehl, T. Schonwald, O. Bringmann, and W. Rosen-stiel. Formal performance analysis and simulationof UML/SysML models for ESL design. In Proc. ofthe Conf. on Design, Automation and Test in Europe(DATE), March 2006, Germany. IEEE, pages 242–247.
[7] OMG. UML Profile for Schedulability, Performance,and Time Specification v1.1. OMG, January 2005.OMG document number: formal/05-01-02.
[8] C. Andre, F. Mallet, and R. de Simone. Modelingtime(s). In MoDELS 2007, LNCS 4735, pages 559–573, Springer Verlag, October 2007.
[9] B. Selic. A systematic approach to domain-specific lan-guage design using UML. In 10th IEEE InternationalSymposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC’07), pages 2–9.IEEE, 2007.
[10] C. Andre. Computing SyncCharts Reactions.Electronic Notes in Theoretical Computer Sciences,88(9):3–19, 2004.
40
Tool Support for a Scheduling Analysis View
Matthias Hagner and Michaela HuhnInstitute for Programming and Reactive SystemsTechnical University of Braunschweig, Germany
{hagner, huhn}@ips.cs.tu-bs.de
Abstract
Correct timing is an important issue of embedded, real-time systems. Nevertheless, it is still difficult to incorporateconsiderations on timing into widely used, model based de-velopment approaches as it is at most in parts supported bymethods and tools. With the new UML profile MARTE, astandard was defined to improve the specification of timingrequirements and to prepare models for analysis.
On the basis of MARTE, we propose a specific schedul-ing analysis view to support separation of concerns. Thescheduling analysis view extends of the usual design views,but focuses on the specification and analysis of real-timeaspects. It explicitely facilitates tentative design steps in anarchitecture exploration process. Modelling guidelines andtool support for specifying realtime constraints and com-pleting a model for analysis are provided.
1 Introduction
Model based development is widely appreciated in theembedded systems domain to cope with the complexity.As a generic and standardized approach UML [1] has es-tablished as one of the most important notations for mod-elling software and with the extension SysML [2] the scopewas expanded to system modelling. The recently publishedMARTE profile (UML Profile for Modeling and Analysisof Real-Time and Embedded systems) [3] makes domainspecific ideas relevant for real-time and embedded systemsdesign available in a unified modeling framework.
The MARTE specification offers a number of differentelements to extend various views relevant for design withinformation on several non-functional runtime properties, inparticular timing. But because of the size and complexity ofthe profile it may be hard to handle the profile for a normaldeveloper. Consequently, the successful application of theMARTE profile in practice requires guidance in terms of
methodology and tool support and a clear focus on thoseelements that directly contribute to the specific goals thedeveloper wants to achieve at a certain design stage.
Moreover, we argue that independent, non-functionalproperties should be handled separately to allow the devel-oper to concentrate on the particular aspect he/she is cur-rently working on and masking those parts of a model thatdo not contribute to it. This is drawn upon cognitive loadtheory [4] which states that human cognitive productivitydramatically decreases the more different dimensions haveto be considered at the same time. Adopted to the designand analysis of a RTE system, we suggest a separated anal-ysis view for the functional design and each relevant non-functional property. For each non-functional property thecorresponding analysis view is built upon the functional de-sign models by abstracting from parts that are irrelevant forthat property but refining and completing the model withinformation related to the property under consideration. Inthis paper, we focus on timing and scheduling behaviour.
Besides specification and tracing of timing requirementsthrough different design stages, the major goal of enrichingmodels with timing information is to enable early validationand verification of design decisions wrt. their implicationson the timing behaviour. As the design for an embeddedor safety critical systems may have to be discarded if dead-lines are missed or resources are overloaded, early timinganalysis has become an issue and is supported by a numberof specialized analysis tools like SymTA/S [5], TIMES [6],or MAST [7]. However, the metamodels on which anal-ysis models of the tools are based differ from each otherand in particular from UML or SysML models used fordesign. Thus, model transformation is needed to build aninterface that enables automated analysis of a MARTE ex-tended UML model using existing RT analysis technology.We demonstrate tool support for the proposed schedulinganalysis view as an extension for Papyrus for UML1.
1http://www.papyrusuml.org
41
2 The MARTE Profile
MARTE [3] is a recent UML profile proposed by the“ProMarte” consortium2 with the goal of extending UMLmodelling facilities with concepts needed RTE systemsdesign like timing, resource allocation, and other non-functional runtime properties. The MARTE profile is a suc-cessor of the Profile for Schedulability, Performance, andTime (SPT Profile) [8] and the Profile for Modelling Qualityof Service and Fault Tolerance Characteristics and Mecha-nisms (QoS Profile) [9].
The profile consists of three main packages. The MARTEFoundations package defines the basic concepts to designand analyze an embedded, real-time system. The MARTEDesign Model offers elements for requirements capturing,the specification, the design, and the implementation phase.Therefore, it provides a concept for high-level modellingand a concept for detailed hard- and software description.The MARTE Analysis Model defines specific model abstrac-tions and annotations that could be used by external tools toanalyze the described system. Thus, the analysis packageis divided into three parts, according to the kind of analy-sis. The first part defines a general concept for quantitativeanalysis techniques; the second and third parts are focusedon schedulability and performance analysis.
Because runtime properties and in particular timing areimportant in each development phase, the MARTE profileis applicable during the entire development process, e.g. todefine and refine requirements, to model the partitioning ofsoftware and hardware in detail, or to prepare and completeUML models for transformation to automated scheduling orperformance analysis [10].
3 Separating Concerns
The cognitive load theory [4] states that human cogni-tive productivity dramatically decreases the more differentdimensions have to be considered at the same time. As aconsequence in software engineering a number of clearlydifferentiated views for architecture and design have beenproposed [11]. Each view focuses on a particular concernas for instance the physical structure with the deploymentor the process view illustrating the situation at runtime withsequential and concurrent executions and synchronizations.The MARTE proposal is to extend such architectural andmore detailed design views with annotations relevant fortiming and other RTE relevant non-functional propertieslike memory allocation, power consumption but also reli-ability or maybe safety. Several of these aspects have to betaken into account in almost each design stage, and more-over, some model elements may be decorated with multi-ple annotations for the same property representing different
2http://www.promarte.org
kinds of information like e.g. required deadlines, and es-timated, measured, or verified worst case blocking times.Thought to the end, adding all different aspects into one de-sign view will lead to an overloaded model probably notwell suited for further design. This thesis was affirmed byindustrial cooperation partners [10] who have long practicalexperiences with methods and tools for model based systemdevelopment.
An obvious solution is to handle essentially independent,non-functional properties separately to allow the developerto concentrate on the particular aspect he/she is currentlyworking on and mask those parts of a model that do notcontribute it. Therefore, we suggest using one view per eachrelevant RTE aspect that is derived from the design model.
Thus, in Section 4 we present the scheduling analysisview. This view is based on the MARTE profile. It onlyuses a small number of selected stereotypes and tagged val-ues to limit the complexity and make it easier to understandand to use. The selected MARTE stereotypes and taggedvalues are sufficient to add the necessary information for ascheduling analysis. Besides this, the view leaves out allinformation from the design model, which is not relevantfor timing. Furthermore, we give guidelines, how to use theelements of the view to describe certain scheduling/timingaspects.
In addition, CASE tools should support this concept. Asa first step, we present an extension that gives the developerthe possibility to create a scheduling analysis view withouta deeper knowledge about the MARTE profile. Using thisextension, the developer does not need to care, how to applya stereotype or what stereotype has to be applied e.g. to adda processor to the model. In addition, another extension weare working on helps the developer to analyze the modelledsystem automatically based on the UML model. These twoextensions are reducing the dimensions a developer has toconsider, and therefore increase productivity.
4 The Scheduling Analysis View
In this section, we introduce the scheduling analysisview, which concentrates on and highlights timing andscheduling aspects. This view is comparable to the processview of the “4+1” views introduced by Philippe Kruchten[11], even though the process view does not cover all neces-sary aspects of the scheduling analysis view. The schedul-ing analysis view was designed regarding the informationneeded for an analysis by a number of tools that are spe-cialized to analyze the scheduling behaviour of systems(SymTA/S, TIMES, or MAST). The view is derived fromthe design view. Moreover, some details have to be addedfor the view because the information is not part of the designview but required for an analysis: It is necessary to definepriorities, scheduling algorithms, task execution times, etc..
242
Other details of the design model are left out because theyare not relevant for an analysis (e.g. information about thedata structure).
For a scheduling analysis it is naturally not sufficient toregard only the software part. Therefore, the hardware (e.g.processors or busses) has to be considered as well. Eventhough it is possible with the MARTE profile to describethe hardware in detail, it is not necessary for a schedulinganalysis. Hence, it is left out and has to be considered in adifferent view with a different purpose. For the schedulinganalysis view, the hardware elements are added to describedistributions and mappings of processes on resources.
The scheduling analysis view enables the possibility toseparate between requirements, variants, and design deci-sions. Some of the added scheduling parameters can beuncertain, estimated with a confidence interval, or tempo-rary. This is necessary if the parameters are not finally de-termined. But for an analysis, values have to be given toall parameters: The execution times can be estimated fromexperts, measured from previous projects (e.g. if COTS3 el-ements are used), or examined by tools like aiT [12]. Otherparameters, like priorities or resource allocations are un-known in early development phases. Therefore, they shouldnot be part of the design model. To keep this information fortiming exploration separated from requirements and designdecisions, they are only added to the scheduling analysisview. If the results of the scheduling analysis based on thetemporary parameters are promising, the approved annota-tions may be carried over as design decisions in the designmodel.
The view consists of three different UML diagram typesand a selection of MARTE stereotypes and tagged values.The diagram types are class diagrams as an architecturalview (to describe the structure, associations, and alloca-tions of the systems’ elements), object diagrams as a viewon the runtime system (to instantiate the concrete systemthat should be analyzed), and activity diagrams as a work-load view (to describe workload situations, flows, and de-pendencies of tasks). The selected stereotypes and taggedvalues are listed in Table 4.
4.1 Architectural View on the System
Class diagrams are used to describe the structure of themodelled system. They show resources, tasks, and associa-tions between these elements. Furthermore, schedulers andother resources, like memory, can be defined.
Figure 1 shows a class diagram of the scheduling analy-sis view that describes the architecture of a sample system.The functionalities/the tasks and communications are rep-resented by methods. The tasks are described using the“saExecStep” stereotype. The components communicate
3Components Off The Shelf
with each other over a bus. The methods that representthe communication are extended with the “saCommStep”stereotype. The task or communication methods are part ofschedulable resource classes. These classes are marked us-ing the “schedulabeResource” stereotype and combine tasksor communication that belong together, e.g. as they are partof the same use case or all of them are service routines. Thetasks and communications are mapped on resources (likeprocessors or busses). This is done using associations be-tween the schedulable resource and the corresponding busor processor resource. The associations are extended withthe “allocated” stereotype. Communication resources havethe “saCommHost” stereotype and processor resources havethe “saExecHost” stereotype.
<<saExecStep>> getData()
<<schedulableResource>>
GUI
<<saCommStep>> send()
<<schedulableResource>>
Communiction
<<saExecStep>> store()<<saExecStep>> backup()
<<schedulableResource>>
DataControl
<<saExecHost>>
HMICPU
<<saCommHost>>
Ethernet
<<saExecHost>>
ControlCPU
<<allocated>><<allocated>> <<allocated>>
Figure 1. A structure of a real-time system
Scheduling relevant parameters can be added to themodel using tagged values (see Figure 2). Thus, it is possi-ble to define deadlines, execution times, priorities, etc..
<<saExecStep>> store()<<saExecStep>> backup()
<<schedulableResource>>
DataControl
deadline=(5,ms)priority=5respT=[$r1,ms]execTime=[1,ms]
Figure 2. A tagged value to add schedulingrelevant parameters
4.2 Runtime View on the System
As class diagrams describe the architecture of a system,object diagrams present the concrete runtime system thathas to be analyzed. The object diagram is based on the classdiagram of the scheduling analysis view and defines howmany instances are part of the runtime system. It is pos-sible that only some elements defined in the class diagramare instantiated. Furthermore, some elements can be instan-tiated twice or more (e.g. if a processor is redundant). Onlyinstantiated objects are taken in account for the schedulinganalysis. In Figure 3 an object diagram defining a concretesystem is shown.
343
Stereotype used on Tagged ValuessaExecHost Classes, Objects Utilization, Scheduler
saCommHost Classes, Objects Utilization, Schedulerscheduler Classes, Objects schedPolicy, otherSchedPolicy
schedulableResource Classes, ObjectssaSharedResources Classes, Objects
saExecStep Methods deadline, priority, execTime, respTsaCommStep Methods deadline, priority, execTime, respT
saEnd2EndFlow Activities end2endT, end2endD, isSchedgaWorkloadEvent Initial-Node pattern
allocated Associations
Table 1. Elements of the scheduling analysis view
<<schedulableResource>>
communication:Communiction<<schedulableResource>>
gui:GUI<<schedulableResource>>
dataControl:DataControl
<< saExecHost >>
hMICPU:HMICPU<< saCommHost >>
ethernet:Ethernet<< saExecHost >>
controlCPU:ControlCPU
<<allocated>> <<allocated>><<allocated>>
Figure 3. An object diagram defining the run-time system
The response times can be calculated using the analysistools and afterwards transferred back into the model (wherethe variable r1 is defined in Figure 2).
4.3 Workload Situations
Activity diagrams are used to describe the behaviour ofthe system. Therefore, workload situations are defined.Workload situations outline the flow of tasks that are exe-cuted during a certain mode of the system. The dependen-cies of tasks and the execution order are illustrated. The“gaWorkloadEvent” and the “saEnd2EndFlow” stereotypesare used to describe the workload behaviours more detailed.The corresponding tagged values offer opportunities to de-scribe the arrival pattern of the event that triggers the flow.In this diagram the hardware is not considered. The tasksare connected independent if they are scheduled on the sameresource or not. Figure 4 gives an example of an activity di-agram. There is well defined, that at first gui.getData() hasto be executed, before communication.send() is scheduledetc..
5 Tool Support for Papyrus for UML
Because of the difficulty to keep in mind numerous com-plex modelling rules and to know all necessary stereotypesand tagged values of the MARTE profile (see Section 3),
gui.getData()
communication.send()
datacontrol.store()
<<saEnd2EndFlow>>
Figure 4. An activity diagram that describesthe flow/the dependencies between tasks
we created an extension of the palette of Papyrus for UMLto support the creation and handling of a scheduling anal-ysis view. Additionally, to support the development flowand to help to analyze the modelled system, we are creatingan automatic transformation to the scheduling analysis toolSymTA/S.
5.1 Papyrus for UML Palette Extension
To help developers to concentrate on the timing andscheduling behaviour and their analysis, we have built apalette extension for Papyrus. The concept for this is basedon the scheduling analysis view (see Section 4). The ex-tension includes support for an uncomplicated creation ofelements that represent e.g. processors, busses, schedulableresources, and shared resources.
Figure 5 shows the palette extension of the Papyrus
444
menu. The developer chooses one of the elements, dragsand drops it into a corresponding diagram. If the developerwants to add a processor to the scheduling analysis view,he has to select an element called “CPU” from the palette,drags it to the class, and as a result a class with the “saEx-ecHost” and the corresponding tagged values is added tothe model. Analogously it works with the other elements.The palette extension includes support for all three diagramtypes needed for the scheduling analysis view.
Figure 5. Palette extension for the creation ofa scheduling analysis view
The selected elements for the palette are sufficient to cre-ate a scheduling analysis view that can be used as an inputfor scheduling analysis tools like SymTA/S and TIMES.This palette extension makes it easier and faster to createscheduling analysis views, even if the developer has lessknowledge of the manifold possibilities of the MARTE pro-file.
5.2 Transformation to SymTA/S
To finally give predictions or verifications concerning thetiming behaviour, it is necessary to use scheduling analysistools. Because it is one of the main purposes of the schedul-ing analysis view to be an input for an analysis, the gap be-tween the UML models and the scheduling analysis toolshas to be by-passed. The metamodels of UML CASE toolsand timing analysis tools differ and thus, an analysis on thebasis of UML models is only possible after a transforma-tion from the UML metamodel into the metamodel of thechosen scheduling analysis tool.
We are developing a plugin for Papyrus that transformsthe information from the scheduling analysis view into themetamodel of SymTA/S automatically. Afterwards the plu-gin starts the analysis and publishes the results back in the
scheduling analysis view. These transformations are sup-ported through the transformation language ATL [13].
If the system has different workload situations, all thesesituations have to be considered separately. Therefore, ev-ery workload situation has to be transferred independentlyinto the SymTA/S format and has to be analysed individu-ally.
6 Evaluating the Palette Extension with Stu-dents
As a first step to prove the efficiency of the Papyruspalette extension we have evaluated it with students. There-fore, we prepared an exercise were the students had to cre-ate a scheduling analysis view for a system out of the rail-way domain: The system consists of trains that have to re-quest permissions to enter a certain track sections. A con-trol centre has to give them the permission fast enough thatthe trains do not have to break and wait for it. The systemand the timing requirements were explained. Furthermore,the scheduling analysis view was already content of the lec-ture. The students nearly finished their bachelors and hadvery good knowledge about UML and modelling, but theywere less experienced with scheduling and scheduling anal-ysis. Nevertheless, they received a brief introduction intothe topic during the lecture where the scheduling analysisview was described.
For the exercise, we divided the pool of students into twogroups with the same number of equally good educated stu-dents. All students had to solve the exercise on their own.One group was allowed to use the palette extension; theother group did not have the extension.
To find out, if it is more efficient to use the palette exten-sion for the scheduling analysis view, we formulated somequestions that we observed during the exercise. We foundthese questions using the goal-question-metric [14]. Thequestions we were interested in were: How many studentsare able to fulfil the exercise? Which group is faster solvingthe exercise? Is there a significant difference between bothgroups concerning speed and quality of the model? Whatquestions do the students have? Are they asking about thescheduling analysis view or are they asking about the con-tent of the exercise?
One result of this test is, that the group that used the ex-tension was more successful fulfilling the exercise. Morethen 50 % were able to create a correct and completescheduling analysis view without any help of the supervi-sor. The rest had problems with the content of the exercise.The reason therefor is less knowledge about scheduling andscheduling analysis. They had problems with definitionsof scheduling terms or general problems to understand theconcept of a scheduling analysis. The students that were not
545
allowed to use the palette extension were not as successfulas the others. About 25 % were able to create a schedulinganalysis view. The other students failed to fulfil the exer-cise in the demanded time. Besides the same problems, theother group had with the content of the exercise, one chal-lenge was the usability of the tool because the schedulinganalysis view was not supported. It was difficult for the stu-dents e.g. to add stereotypes or to find the correct stereotypeor tagged value to describe certain elements.
This result confirms us with the opinion that the schedul-ing analysis view and the corresponding tool support arebenefits for developers of industrial, time critical systems.
7 Conclusion and Future Work
We have presented a scheduling analysis view. A viewthat concentrates on the UML and UML profile elementsneeded for a scheduling analysis. It reduces the designmodel on the one hand side to the necessary elements andextends the model on the other hand side on elements,which are not part of the design model, but needed foran analysis. Besides this, we presented extension for Pa-pyrus for UML to help support the creation and usage of thescheduling analysis view. The extension of the palette sup-ports developers to create a view without deeper knowledgeabout MARTE. The automatic transformation to the analy-sis tool SymTA/S supports the development flow and makesa fast analysis possible. We have evaluated the palette ex-tension with students with the result that the extension in-creases the efficiency.
A future work will be to examine, how to handle pa-rameters, which have a different status at a certain designstage, e.g. if they are based on design decisions, temporary,guessed etc.. MARTE provides possibilities to add notes toparameters, like measured, calculated, or determined. Butthere are guidelines needed to make sure, how to handlethese notes. Furthermore it is necessary to extend that con-cept to mark e.g. mappings or other information that is partof a MARTE timing model as temporary or determined.
To complete the picture, also other non functional prop-erties like reliability have to be taken into account whichshould be added as appropriate annotation to the models ina similar way.
References
[1] OMG Object Management Group. Unified modelinglanguage specification, 2003.
[2] OMG Object Management Group. Omg systems mod-eling language (omg sysml), v1.0, 2007.
[3] OMG Object Management Group. UML Profile forModeling and Analysis of Real-Time and Embeddedsystems (MARTE) RFP, 2006.
[4] J. Sweller. Evolution of human cognitive architecture.In The Psychology of Learning and Motivation, vol-ume 43, pages 215–266, 2003.
[5] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter,and R. Ernst. System level performance analysis -the SymTA/S approach. IEEE Proceedings Comput-ers and Digital Techniques, 152(2):148–166, March2005.
[6] E. Fersman and W. Yi. A generic approach to schedu-lability analysis of real-time tasks. Nordic J. of Com-puting, 11(2):129–147, 2004.
[7] M. González Harbour, J. J. Gutiérrez García, J. C. Pa-lencia Gutiérrez, and J. M. Drake Moyano. Mast:Modeling and analysis suite for real time applications.In ECRTS ’01: Proceedings of the 13th EuromicroConference on Real-Time Systems, page 125, Wash-ington, DC, USA, 2001. IEEE Computer Society.
[8] OMG Object Management Group. UML profile forschedulability, performance and time, 2002.
[9] OMG Object Management Group. UML profile formodeling quality of service and fault tolerance char-acteristics and mechanisms, 2004.
[10] M. Hagner, M. Huhn, and A. Zechner. Timing analysisusing the MARTE profile in the design of rail automa-tion systems. In 4th European Congress on EmbeddedRealtime Software (ERTS 08), 2008.
[11] P. Kruchten. The 4+1 view model of architecture.IEEE Softw., 12(6):42–50, 1995.
[12] C. Ferdinand, R. Heckmann, M. Langenbach, F. Mar-tin, M.l Schmidt, H. Theiling, S. Thesing, and R. Wil-helm. Reliable and precise wcet determination for areal-life processor. In EMSOFT ’01: Proceedings ofthe First International Workshop on Embedded Soft-ware, pages 469–485, London, UK, 2001. Springer-Verlag.
[13] ATLAS Group (INRIA & LINA). Atlas transforma-tion language. http://www.eclipse.org/m2m/atl/.
[14] V. R. Basili and H. D. Rombach. The tameproject: towards improvement-oriented software envi-ronments. Software Engineering, IEEE Transactionson, 14(6):758–773, 1988.
646
47
Modeling and Analyzisof Real-Time and Embedded Systems
with the MARTE UML profile
In order to cope with the complexity of embedded system design, one of the most promisingtrends is to raise the abstraction level. This allows to abstract away implementation detailsand dramatically speed-up the system architecture exploration. We are currently seeing thegeneralization of ESL (Electronic System Level) design tools but a way to raise even further theabstraction level is to move from languages (like SystemC or System Verilog) to modeling tools.Such tools are more and more used to develop software that is an increasingly important partof embedded systems. The industry standard for modeling software is UML and some efforthas been recently done to adapt UML to the co-modeling of embedded systems. These effortshave lead to the MARTE (Modeling and Analyzis of Real-Time and Embedded systems) UMLprofile that has been standardized by the OMG last August (http://www.omgmarte.org/). It iscurrently in finalization and should become a full standard during the year 2008.
Organization Committee
• Pr. Pierre Boulet, Laboratoire d’Informatique Fondamentale de Lille, Université desSciences et Technologies de Lille, France
• Dr. Oliver Bringmann, FZI Forschungszentrum Informatik an der Universität Karlsruhe,Germany
• Dr. Robert de Simone, INRIA Sophia Antipolis Méditerrannée, France