From Embedded Systems Requirements to Physical...

From Embedded Systems Requirements to Physical Representation: A Model-based Methodology in Accordance with the EIA-632 Standard

Carlos Gómez, Philippe Esteban, Jean-Claude Pascal and Fernando Jiménez

Abstract The conception of system level, introduced in Electronic System Level (ESL), offers a system model representation before thinking on the partition between software and hardware. One of the ESL initiatives is Model-Based Systems Engineering (MBSE). Its objective is to reduce ambiguity of specification interpretation, to verify the specification in early design steps and generate code automatically. In this work, we propose a new design methodology that follows the MBSE principles. Our methodology obeys the EIA-632 standard which defines the well practices on Systems Engineering. It uses SysML as system description language. HiLeS Designer is used as verification tool. We illustrate our methodology in the design of an Intelligent Remote Keyless Entry System. Actually, it is applied to specify and develop new products for a Colombian company specialized in the commercialization and distribution of electric energy.

1 Introduction

The complexity in embedded systems has been increased in the last years. New heterogeneous systems which combine different domains are more com- _________________

Carlos Gómez He did this work at LAAS-CNRS, F-31077 Toulouse, France and now, he is at Université de Nice-Sophia Antipolis, I3S-CNRS, F-06903 Sophia Antipolis, INRIA, F-06902 Sophia Antipolis, France, e-mail: [email protected]

Philippe Esteban and Jean-Claude Pascal CNRS ; LAAS ; 7 avenue du colonel Roche, F-31077 Toulouse Cedex 4, France Université de Toulouse ; UPS, INSA, INP, ISAE ; UT1, UTM, LAAS ; F-31077 Toulouse Cedex 4, France. e-mail: [email protected], e-mail: [email protected]

Fernando Jiménez Universidad de Los Andes, Cra. 1 No. 18A-12 Bogotá, Colombia, e-mail: [email protected]

1

2 Carlos Gomez, Philippe Esteban, Jean-Claude Pascal and Fernando Jimenez

mon. Aircrafts, automobiles, cell phones, medical equipments are systemsexamples where domains such as media, communication, software, mechanicsand physics are part of systems development today.

Markets demand to increase the functionality of the present systems, tomix domains, to anticipate errors in the system development process andto reduce time-to-market delay in order to minimize design and productioncosts (Abdurohman et al, 2009). For instance, systems such as cell phoneshave passed from the simple functionality to talk with other people to addnew functionalities such as SMS, music, videos, Internet, GPS and others,increasing the complexity, adding new systems and reducing their size.

Traditional methodologies in embedded system design are more difficult toapply because of the system complexity, giving as result a difficulty to achievethe time to market and the quick implementation of new technologies whoseprogress increases each time faster (Gajski et al, 2009).

The embedded system design community has begun to raise the abstrac-tion level in the design and a new conception of “system level” is createdto handle the complexity. This new level incentives the reuse (Shukla et al,2006), (Sangiovanni-Vincentelli, 2008) and it allows the development of hard-ware and software parts of a system almost on parallel reducing the systemdesign time.

Electronic System Level (ESL) is one of the answers to guarantee a reliableembedded system design, reducing design time, increasing verification pro-cesses inside the systems design. There are different methodologies which fol-lows the ESL principles in order to design embedded systems. Platform BasedDesign, proposed by Sangiovanni et al. in (Keutzer et al, 2000), (Sangiovanni-Vincentelli, 2007), defines the system level as the split between functionalmodel definition and platform model definition. Once the models are defined,the designer maps the functionality on the platform chosen. Non-functionalrequirements (performance, energy consumption, etc) are evaluated and ifthey are not achieved, a new platform is explored.

Another methodology which works the complexity in system design isModel-Based Systems Engineering (MBSE). It is supported by INCOSE(INC, 2010) and other important institution such as NASA, Boeing, EADS,IBM, Georgia Tech and others. This methodology proposes to change thepaper-based requirements to model-based requirements, where model lan-guages such as SysML (Sys, 2010) can be used to describe the behavior(functionality), structure (architecture) and the allocation of the behavior onthe structure (mapping). After, when the mapping is realized, the designer,who uses model transformation concepts defined in Modeling Driven Archi-tecture (MDA) (Meservy and Fenstermacher, 2005), generates automaticallythe code from functionality definition onto a specified executable language(C, C++, VHDL, etc). Some works have been developed since SysML isan Object Management Group (OMG) standard. The authors in (Kawaharaet al, 2009) propose a SysML extension to represent continuous-time behav-ior, indispensable to model natural behavior such as temperature sensors and

A Model-based Methodology in Accordance with EIA-632 standard 3

video processing. They also present a mapping connection between SysMLblocks to MATLAB Simulink in order to simulate and verify the behavior ofthe SysML model. In (Johnson et al, 2008), the authors define a transforma-tion from block definition and parametric Diagrams to Modelica generatingthe code to execute and verify the model built on SysML.

MBSE community believes to have a graphical language to express thesystems requirements, the stakeholders understand easier the specification,reducing interpretation ambiguities and helping to make easier feedback fromthe stakeholders. It is also possible to verify the specification in the early de-sign steps, transforming the model to a formal formalism or to an executablelanguage. For instance, Petri nets is a well-defined formalism which is usedto verify safety properties (e.g. reachability, blocking, deadlock and lifeless)(Wagenhals et al, 2003) and performance (Andrade et al, 2009) on SysMLand UML models. Finally, thanks to MDA principles (behavior and archi-tecture are split from the technology platform implementation), the designeruses the model transformation to descends easier from one abstraction levelto another, adding different constraints (time, scheduling, etc) to executablemodel without requiring a manual code work. These features reduce designtime, verification time and risk to fault during the system design.

Estefan in his survey presents MBSE methodologies which are at thepresent (Estefan, 2009). Most of them define the well-principles to designsystems without taking into account any standard. Model Driven SystemDesign (MDSD) (Baker et al, 2000) is a methodology which obeys standardrequirements, IEEE 1220 standard (iee, 2005), but they do not specify exactlythe language model to build the system design.

In this chapter, we suggest a methodology iterative in accordance withEIA-632 standard (EIA, 1999). This standard defines a system engineeringprocess to design and to develop a system starting from stakeholder’s require-ments until getting the final product. EIA-632 standard emphasizes on theverification process in each step of the system design. Our methodology isalso based on the method proposed in (Esteban et al, 2005) to develop eachstep in the design process defined by the EIA-632 standard. We completethis method using the new diagrams introduced in SysML and we add thetraceability among the different point of view on SysML. We support ourmethodology using TOPCASED (Top, 2010) as SysML tool and HiLeS De-signer (Gomez et al, 2010c), (Hamon, 2005) as verification model tool. Thislast tool allows verifying a system in two ways: formal verification of thelogical execution based on Petri Net analysis and verification by simulationgenerating an executable virtual prototype in VHDL-AMS.

The aims of our methodology are to reduce the specification interpretationusing SysML as model specification language, to verify in each abstractionsystem design level the behavior of the system using HiLeS Designer and togenerate automatically code in order to evaluate different platforms where thebehavior and architecture of the model specification would be implemented.The verification as soon as possible helps to reduce errors and to take into


account new features that the designers find in the final steps of the systemdesign.

Our methodology is being applied to specify and develop new productsfor a Colombian company specialized in the commercialization and distribu-tion of electric energy. The main interest is to develop a new generation ofIntelligent Electronic Devices (IEDs) in distribution automation application.As Cyberphysical Energy Systems road map remarks (Morris et al, 2009),these companies needs to design secure information architectures to assistdecision systems with increased embedded security at component level inte-grating failure management. This challenge in practice means to add securityaccessories and bridge accessories at IEDs to existing Supervisory Controland Data Acquisition installations or to design new IED components that in-corporate security features and additional processing capacity. An evaluationof different schemes and technological solutions is necessary in order to savemoney in investments required for distribution automation in a distributedgeneration market.

The remainder of this chapter is organized as follows. In section 2, we givean introduction to the EIA-632 standard and we will focus on the systemdesign sub-clause of this standard. In section 3, we describe our proposedmethodology and we illustrate each step on a study case. Finally, we givesome conclusion and future work in section 4.

2 EIA-632: Processes for Engineering a System

According to International Council on System Engineering (INCOSE), sys-tems engineering is an interdisciplinary approach and means to enable therealization of successful systems (INC, 2007). This discipline follows a generalprocess methodology which includes a set of activities in order to conceive,develop and verify a system, resulting in an economic and efficient solutionfor the client necessities, which also satisfies all stakeholders related to thedesign, utilization, maintainability, installation and others.

The purpose of this standard is to provide an integrated set of fundamentalprocesses to aid the developer in the engineering and reengineering of a system(Martin, 2000), (EIA, 1999). This standard recommends 13 processes groupedin 5 themes: Technical Management, Acquisition and Supply, System design,Product Realization, and Technical Evaluation.

We are interested in the “System Design” sub-clause, where the stakehold-ers’ requirements are transformed to Specification, Drawings and Models inorder to design the final product. This sub-clause has two processes: Require-ments Definition Process and Solution Definition Process.


2.1 Requirements Definition Process:

• R-14. Acquirer Requirements: The needs of the customer, user or op-erator that the system has to perform (mission, functions, performance,constraints, services, etc.).

• R-15. Other Stakeholder Requirements: Other requirements which com-plete the acquirer requirements from other parts related to the project.They contain laws, technology, standards, maintenance, commercial re-quirements, etc.

• R-16. System Technical Requirements: Requirements where the relation-ship between the acquirer requirements and other stakeholder require-ments are analyzed. Its results are requirements that are unambiguous,complete, consistent, achievable and verifiable. They are the input to thesystem solution definition process.

2.2 Solution Definition Process:

• R-17. Logical Solution Representations: This solution is a system techni-cal requirements analysis where these requirements, expressed in naturallanguage, are transformed to a logical representation (functional flows,behavioral responses, state and mode transitions, time lines, data flows,etc.). This representation has to be verified. The analysis can lead to otherrequirements which are called “Derived Requirements”.

• R-18. Physical Solution Representations: Having a logical solution repre-sentations of the system, the designer builds a physical solution represen-tation (e.g. virtual prototype) based on the logical solution, the derivedtechnical requirements and the unassigned system technical requirements.In this step are decided the partition software/hardware, the physical in-terfaces, the technology and others concerns to the development of thephysical solution.

• R-19. Specified Requirements: Chosen a physical solution which performsthe logical solution and follows the constraints expressed in stakeholders re-quirements and derived technical requirements, the designer has to specifyrequirements to choose physical components for the system production; itincludes: functional and performance requirements, physical features, andtest requirements.

2.3 Building block

EIA-632 standard defines that the system is represented by a conceptualstructure called “Building Block”. It is a generic structure of the system to


be built. According to the standard, a system is a set of physical or logicalcomponents, services, persons, suppliers, technical features or every otherproduct which takes into account the activities to be considered. A buildingblock consists of End Products (product to be developed or ready to use)and Enabling Products (products which allow the development, the test, theproduction, the installation and so on of end products).

Each End Product and Enabled Product can be decomposed in two ormore subsystems. Each subsystem is a system and it can be split in other sub-systems. The system decomposition finishes when End Products can eitherbe implemented or there exists a solution that fulfills the system requirementsor they can be build by a supplier.

3 Methodology and Study Case: Intelligent Remote

Keyless Entry System

In this section, we explain the methodology steps that we developed and weillustrate them using our study case, an Intelligent Remote Keyless EntrySystem (IRKES). IRKES is a system used in some cars to lock and unlockthe doors replacing the conventional key system. The particularity of thissystem is neither the driver needs to press any button on a remote controlnor to put any key on the car to unlock it. The driver only needs to approachhis hand to the door handle with a key card in his pocket in order to unlockthe doors. The system detects the driver and identifies the user reading thekey card remotely. When the driver moves certain distance away from thecar, the system locks it. For our example, we focus to the development of theunlock doors case.

The methodology uses SysML as description language and each step isin accordance with the EIA-632 standard. Figure 1 depicts a summary ofour methodology. It shows Requirements Analysis follows R-14, R-15 andR-16 Requirements from EIA-632. These requirements are represented bypackage and requirements diagrams in SysML. Once the requirement anal-ysis is finished, the following step is Functional and Architectural Analysis.This step fulfills R-17 Requirement (Logical Solution Representation) fromthe EIA-632. Finally, the specification model is verified using HiLeS and acomponent exploration is executed, accomplishing R-17, R-18 and R-19 Re-quirement. This step is the design phase and virtual prototyping. In addition,this methodology is iterative, that means, each step is repeated for each ab-straction level.


Fig. 1 Methodology Summary Schema.

3.1 Requirement Analysis

The first step in this methodology is to get the stakeholders’ requirements.We use the SysML requirement diagram to describe these requirements innatural language. To classify the requirements, we use SysML package di-agram. Figure 1 depicts the same distribution defined in the requirementsR-14, R-15, and R-16 of the EIA-632, such as Acquirer Requirements, OtherStakeholder Requirements and System Technical Requirements.

In Acquirer Requirements package, a new package is created for each stake-holder who participates in the development of the system. Each stakeholderhas its own contribution to the project and different needs are taken into ac-count to the project development. For each stakeholder, each requirement isclassified in functional, interface, performance and environment requirementsusing also package diagrams. For each classification package, the designer candefine different requirements using the requirement diagram and its relation-ships. The requirement development defined in (INC, 2007) is used to capture,to process and to organize the requirements.

In Other Stakeholder Requirements package, the designer adds new pack-ages for each constraint topic, e.g., standards, environment, laws and rules,and inside of each package, its own classification.

It is possible to make different iterations in the stakeholders’ requirementsanalysis in order to have all the information possible concerning to the system.

In our example, we begin in the high level description that we call Level0. We create different requirements following this step. Figure 2 shows onlyan example of these requirements which are approximately 50 requirements.In this figure, we present two requirements (Unlock doors and Detection


Distance) into Acquirer Requirements package. Each requirement has Iden-tification and its description on natural language.

Fig. 2 Acquirer and system technical requirements example.

When the Stakeholders’ Requirements are finished, the system technicalrequirements are derived from these requirements (From R-14 and R-15 toR-16). These requirements are functions and constraints that the systemhas to fulfill. The description of these requirements is more exact, detailedand atomic, that means, only with one concern (action or constraint) in thedescription of the technical requirement.

The system technical requirements are also represented by a package,where inside of this package, the designer can build a classification, as well ashe did with stakeholder requirements. Inside each classification package, wecreate the technical requirements derived from the stakeholder requirements,specifying its relationship, using deriveReqt connection defined in SysML re-quirement diagram. In this way, the designer draws the traceability betweenstakeholders’ requirements and technical requirements.

Applied it on our example, Unlock doors and Detection distance technicalrequirement are derived (Figure 2). Note that the writing has changed, thesubject is the user which describes his need in the requirement, on the otherhand, the derived requirements into the technical requirements. The suject’srequirements is changed to “system”, because the system has to be the actionwhen the user asks it, in this “case open the door”. Using the relationshipderiveReqt, the traceability between the two requirements levels is defined.

3.2 Functional and Architectural Analysis

Once the System technical requirements are done, the second step of ourmethodology is to build the logical solution representation of the system,


according to R-17 requirement of EIA-632 standard inside Solution DefinitionProcess. We split this solution in two representation groups: Behavioral andStructural.

The behavioral representation describes the dynamic of the system. In thisrepresentation, actors, use cases and the relationship between the system andits environment is defined. This definition is represented in SysML use casediagrams. Once the use cases are defined, the scenarios, which described thesequential interaction between actors (environment) and the system involvedin the use case, are built. These scenarios are defined from the user’s point ofview. Each use case has to be related with a system technical requirementsand each sequence diagram describes a use case.

Continuing on our example, we describe the first behavioral descriptionusing SysML use cases diagram (Figure 3). This diagram presents four usecases: Detect a user, Identify the user detected, Unlock the doors if the user isauthorized and Lock Doors, when the user goes the car away. Detect, Identifyand LockDoors use cases are related to User actor, which actives the systemto be detected and identified, and the user also indicates to the system that ithas to lock the door when the user goes the car away. Defined the use cases,we develop the scenario for each use case using a SysML sequence diagram.Figure 4a shows the scenario to detect a user when he approaches his handto the door handle (Detect use case). As the figure shows, the system hastwo possible executions, the first option is when the car is parked more than3 days and the other one is when it is parked less than 3 days.

Fig. 3 IRKES use cases diagram.

The first option, the system is in sleeping mode, which means that sleepingtime is achieved and the system sends to itself the signal that the sleepingmode starts (endSleepingTimer). After, the user approaches to the car and asthe system is in sleeping mode, it has to press the button of the handle door.This action is received by the system using pressButton() function. Once thesystem receives the signal, it wakes up and starts to detect the user if it isclose to the handle door.


Fig. 4 Level 0: Main interaction between the IRKES and the user.

The second option on the sequence diagram is when the car is on idle state,which means, it waits the user presence. When the user approaches his handto the handle door, the system detects it and it decides to stop the sleepingtimer. After, presence() function is activated by the system in order to startthe identification process.

Once the behavioral representation is defined, we continue with systemstructural description. It is the static part of the system. In this group, is pro-posed a logical architecture, where the functionality of the system is groupedby subsystems. Also in this group, the relationship among the system, itssubsystems and its environment is defined by services. These services help toindicate the functionality that each subsystem offers or requests. They alsohelp to re-use components in other projects.

The structural description is split in two levels or packages: CompositionDefinition and Constraints. The composition definition package contains thesystem architecture definition on logic level. On the other hand, constraintspackage contains constraints that the system has to achieve. Inside Compo-nents Definition, there is other classification: Hierarchical Composition andPorts and Services Definition.

The Hierarchical Composition package contains a SysML Block DefinitionDiagram (BDD) that is used to define components represented by lifelines inthe sequence diagram. The lifeline is represented by a block where its meth-ods (internal functions which are called by services), its properties and itsconstraints are related. In this package, it is also defined the system hierar-chy. This hierarchy represents abstraction levels of the system, starting from


a high level description to a detailed one. This representation is according tothe concept “building block” proposed in EIA-632. Inside of the block whichis decomposed in blocks, we can create an internal vision using the SysMLInternal Block Diagram (IBD). This diagram allows using the services whichare offered or requested by the block parts. It also defines the relationshipamong block parts. These services are derived from the lifelines’ messagesdefined in the sequence diagram and they are defined in the Ports and Ser-vices Definition package. Ports are the structural connection among blocksand their environment.

In our example, we build Component Definition illustrated on Figure 4d.At this level, we describe the system with a block inside the Components Hi-erarchy package because there is only one lifeline which represents the system(IRKES block). On Detect use case, services for messages pressButton() andapproachHand() are defined in Detection interface that is tied to the port Det(Figure 4c). The other messages inside the system (e.g. endTimerSaver() andstopTimerSaver()) are system operators (figure 4d).

Finally, constraints are defined. These constraints are represented by apackage which expresses system constraints using BDD. Like BDD used inComponents Hierarchy package, each constraint is represented by a block, butin this case, it is called “Constraint block”. These blocks can be split intosub-blocks where the meaning of this partition is to calculate the value of theblock by the calculus result of their sub-blocks. The relationship between sub-blocks inside a block is represented by a SysML Parametric Diagram whereeach sub-block inside of a block is called “Part”. Each part has an equationor algorithm which executes a function. Each variable of these equationsor algorithms is represented by ports called “Parameters”. Each parameteris related with other parameters using connectors. Peak et al. (Peak et al,2007a), (Peak et al, 2007b) shows the possibility to transform the SysMLParametric Diagram in an executable model to verify the constraints andtheir relationships.

Parameters have a type joined. In system engineering there are many typesto describe a property, such as time, frequency, length, speed, and others.These properties generally have a value and a unit.

The units can be from different measure systems such as the InternationalSystem of Units. We follow the types definition proposed in (Sys, 2010) and(Weilkiens, 2008).We create a new package dedicated to define data types andthis package is at the same level of Requirement package, Structural packageand Behavioral package in order to be used in the variables definition.

Following the methodology, we define system constraints on our example.Figure 4b depicts a constraint example related to Detect use case, which isthat the detection distance is 30 mm. This constraint is linked to the definedblock as a component constraint, e.g., CDetectDistance constraint (figure 4b)is linked to IRKES block (figure 4d) as Reference, that means IRKES blockis constrained by CDetectDistance.


When the structural definition is finished at a given abstraction level, therequirements are connected to the blocks to complete the traceability of ourmethodological steps. Every requirement has to be represented in a block;it includes functional, performance, interface and environment requirements.The traceability is defined between the hierarchal components and the con-straints. The constraint blocks has to be related to the block where is appliedthe constraint. These traces give an idea that our logical solution representa-tion satisfies the requirements generated in the first step of our methodology.

In our example, Figure 5 shows the traceability. For instance, IRKES-STR-001 requirement is refined by Detect, Identify and UnlockDoors usescases using refine connection. At the same time, IRKES block satisfies thisrequirement (satisfy connection). Each element created in the functional andarchitectural analysis must have a relationship with requirements, exceptsequence diagram elements which are related with blocks in Block DefinitionDiagram and Internal Block Diagram.

Fig. 5 Traceability among behavioral, structural concepts and requirements.

3.3 Abstraction Levels

The methodology steps are applied in different abstraction levels. Each levelrepresents the system description detail. It helps to consider the system asa black box, defining its interaction with the environment and after its fea-tures can be distributed to different internal components in the following


abstraction levels. This is the same building block philosophy described inEIA-632.

As we show on the example, we begin at Level 0, where is defined theinteraction between the system and its environment. In other levels, the sys-tem partition is defined. In terms of the EIA-632 building block, the systemis split in subsystems. This partition is derived from messages and actors de-duced at Level 0. Some messages can be grouped in a subsystem and they aretied to the action domain, functionality and others. The partition criterionis given by the designers and they will find the best way to do a logic parti-tion. They can guide their criterion based on the messages described in thesequence diagram. Messages, which have a common target, can be groupedin a subsystem. It is important to advice that this first partition has to bethe most general as possible; this cannot include any details such as sensormodels, keyboard events, etc.

Finishing Level 0 on our example, we do a new iteration of our method-ology on a new abstraction level. At Level 1, we analyze Detect sequencediagram built at Level 0 and we split the system lifeline in three lifelines(Detector, TimeSaver, Identifier) guided by the messages defined previouslyand the domain features (Figure 6(a)), e.g., Detector is defined because ofpressButton() and approachHand() messages. We deduce that this subsystemis the activator of the system, and it can be represented by one subsystem. Onthe other hand, SleepingTimer is a lifeline that controls the system time tosuspend or not the system. Messages are also distributed in derived lifelinessuch as endSleepingTimer() and presence() on Figure 6(a)). Lifelines distri-bution in the sequence diagram follows the EIA-632 building block concept,where the main lifeline (system) is spitted in specialized lifelines (subsys-tems).

Leve1 1 of Detect sequence diagram is shown in figure 6(a). In this dia-gram, there are two execution options such as level 0, when the car is parkedmore than 3 days and when it is not. In the first option, the system is sleepingand now Sleeping Timer announces to Detector that the system is in sleepingmode. Therefore, the user has to press the button on the handle door in or-der to change the system state (sleeping mode to idle mode). After, Detectorinits Identificatior to identify the user which presses the button. The secondoption, the user only has to approach his hand, Detector stops the sleepingtimer counter, and the presence is announced to Identificator.

In figure 6(b), Identify sequence diagram is shown. This scenario beginswhen the user is detected in the previous scenario using presence() message.Once the user is detected, Identificator asks the user identification. If the userhas an ID card, then Identificator asks for its ID, else Identificator starts thesleeping timer count. When the ID is received, and the ID corresponds to theID stored into Identificator, it sends a message to Locking Control to openthe doors, else it starts the sleeping timer counter.

There is a lifeline in common, between Detect and Identify sequence dia-grams called SleepingTimer. The sequence diagrams lifelines and the inter-


section between the two scenarios are mapping to Block Definition Diagram(BDD), representing each lifeline from the two sequence diagrams to blocks(figure 7(a)). In this diagram, the first hierarchy level of our design is built.

Services and ports are defined into Ports and Services package for eachnew message created in the two sequence diagrams. At this level, it is possibleto build the internal description of our system using a SysML Internal BlockDiagram (IBD) (figure 7(b)). Each sub-block, which composes IRKES blockin BDD, is a “Part” in IBD. New defined services and ports are used in thisdiagram to define the relationship between IRKES parts and it follows thesame relationship defined in the sequence diagrams. For instance, approach-Hand() message is a service offer by Detector lifeline whose requester is theuser, which is extern to the system. This lifeline is represented by Detec-tor block in the architectural definition and it is part of IRKES system. Itsservice is used in IBD as a relationship between Detector part and IRKESsystem environment.

Constraints defined at Level 0 descend to its subsystems. At this level,each subsystem can be considered as an independent system with its ownrequirements, constraints, functionality and architecture.

When the structural definition is completed, the system is verified usingHiLeS Designer. This step is repeated each time that a new abstraction levelis developed. The verification checks that the system model development isaccording to requirements previously defined and it is possible to find outbehaviors non-specified into the requirements.

3.4 Model Verification

The third step in our methodology is model verification. It is applied at eachabstraction level. At this point, it is possible to verify that our SysMLmodel isaccording to the stakeholders’ requirements. We transform this SysML modelrepresentation to HiLeS formalism (Hamon et al, 2004) using the MDA con-cepts. This tool has been used in different academic and industrial projects,e.g., System Display Selector used in Airbus airplanes (Gomez et al, 2010a)and a cane sugar production process (Gomez et al, 2010b).

HiLeS is a graphic language that has four main concepts: Structural block,Functional block, Control net and channels. The structural block representsthe system hierarchy in each abstraction level. According to EIA-632, a struc-tural block represents a “building block”. On the other hand, the functionalblock is the atomic representation of a unique function. It defines part of thebehavior description on the last abstraction level. The control net describesthe execution logic sequence of blocks (functional and structural) defined in asystem model. It is represented by an ordinary Petri net. Finally, channels areroutes which transmit the information from the environment to the system,from one block to another and the control net to blocks. They are defined


(a) “Detect” Sequence Diagram

(b) “Identify” Sequence Diagram

Fig. 6 Level 1: Identifying main subsystems.

in two types: Control and Continuous. Control Channels manage the blocksexecution, and Continuous Channels route signals from blocks to blocks orenvironment to system, according to their nature.

The SysML model transformation begins with the sequence diagram trans-formation to Petri Nets and the structural representation (Block DefinitionDiagram and Internal Block Diagram) to structural and functional blocks.At this time, the transformation is manual based on the work (Ouardaniet al, 2006) where the transformation rules from sequence diagram to PetriNets are defined. Each block in BDD and IBD are manually transformed tostructural and functional block and the selection between one block and otherdepends on the abstraction level, i.e., if a block in SysML has internally otherblocks then this block will be transformed to a structural block, if it has not,it will be transformed to a functional block which will contain the executabledescription of the SysML block which represents.

The executable logical behavior is automatically completed on HiLeS leveland a virtual prototype is generated by the HiLeS Designer tool (Hamon,2005). This tool allows verifying formally the logical behavior using TINA


(a) Block Definition Diagram (First hierarchical level)

(b) Internal Block Diagram (Blocks relationship)

Fig. 7 Level 1: Architectural Definition.

(Berthomieu and Vernadat, 2006), which is a Petri net analyzer, and verifyingby simulation the behavior of the system using the virtual prototype gener-ated in VHDL-AMS (Nketsa et al, 2004),(Albert et al, 2005). In this step, thelogical solution representation is verified according to EIA-632 requirements.

Figure 8 depicts an example of this representation on IRKES. In the firstlevel (Level 0 ), the figure shows the system as a black box related with theenvironment. Inside the environment block, test scenarios are defined forverifying the stakeholders’ requirements. They are used in the verificationprocess. Next, the second HiLeS level is described according to level 1 inthe SysML model. Each block is represented by a structural block and theiterations by channels. Finally, the behavior of each structural block is de-fined according to the System Technical Requirements. The figure shows theinternal description of Identificator block. The block contains two functional


Fig. 8 First two levels of IRKES in HiLeS.

blocks, DetectionTimer and ComparatorID, and a Petri net which controlthe functional blocks execution. DetectionTimer block manages the time toactivate the sleeping mode when it is not used. ComparatorID identifies ifthe user card is registered or not in the system.

To give an example, how a requirement is validated on HiLeS Designer,we give the following requirement:

• IRKES-STR-006: If the user is identified as “valid”, the system mustunlock the doors.

The formal verification is used to know if the logical HiLeS model behav-ior (Petri net) is not blocked in some place, that every transition is firedand that any possible combination to execute the model is not blocked. Thisverification is possible using TINA through HiLeS Designer, to analyze math-ematically the logical model represented on Petri nets. In Figure 9(a), partof Identificator block analysis result is shown. The analysis presents the pos-sible execution combination (Marking) of the Petri net inside Identificatorblock. We are interested on the place that represents the event to unlockthe doors, when the user is identified as valid according to the requirementIRKES-STR-006. This place is Pl 23 following Identificator internal blockdescription. On the analysis, it is possible identify two marking which con-tains Pl 23 place, marking 6 and 10 which show that the model achieve theValid state, any of the states modeled are death and they are not executedseveral times at the same time. This result confirms that our model in thisfirst verification is according to the requirement IRKES-STR-006.

As second step in our model verification, we transform our HiLeS model toa virtual prototype in VHDL-AMS in order to verify our model by simulation.HiLeS designer generates the VHDL-AMS code automatically from the HiLeSmodel. Figure 9(b) shows Detect scenario simulation which is according tothe IRKES-STR-006 requirement. This scenario shows that the system is in


sleeping mode and the user presses the button twice to active the system andto open the doors. On the simulation, the system detects the door handlebutton event (third signal (1: pressed, 0: released) in Figure 9(b)), thus itwaits a second the door handle button event to active the system. Whenthe user pressed for second time, the system is activated (the sleeping modeis stopped, the second signal (1: active, 0: inactive) in the figure), the useris identified and it unlocks the doors (first signal (1: unlock, 0: lock) in thefigure).

(a) Marking of the“Identify” block

(b) “Detect” scenario simulation.

Fig. 9 Verification using HiLeS Designer.

Fig. 10 Identificator Block Physical Solution Representation.


3.5 Physical solution exploration

Once our model is verified, the final step is to search physical componentswhose behavior is according to the virtual prototype and services that sub-systems offer and request. The system, decomposed in subsystem, helps tofind a physical representation according to its functionality and interfaces.It also helps to the development of new subsystem, making easier and in anearly mode the partition software/hardware related each part to a specificsubsystem.

If there are physical components that fulfill the virtual prototype behaviorand services defined in the logical representation solution, the methodologyiteration can be stopped for the evaluated subsystem. The logical descriptionsolution is replaced for the virtual prototype which simulates the physicalcomponent behavior, in other words, according to R-18 requirement of theEIA-632 standard, to replace the logical solution representation for the phys-ical solution representation. If it is not possible to find any physical com-ponent, it is necessary to begin a new abstraction level, decomposing thesubsystems without solution and repeat the steps explained before.

The designer can descend to the necessary levels until to get a developedsubsystem or to develop an abstraction degree level where the supplier hasto build and design everything according to the specified requirements (re-quirement R-19 of EIA-632).

On our example, we implement a physical solution composed by FPGA anda transceiver for the logical solution of the Identificator system in the level1 (Figure 8). In figure 10, the FPGA solution implements the logical controldescribed by Petri net (CtrlIdentificator) and TimerDetector functional block(the two CounterTx blocks) showed in the HiLeS description. The transceiverimplements Comparator ID functional block.

4 Conclusion and Future Work

This work proposes a new methodology to design embedded systems follow-ing MBSE principes which is part of the ESL design concept. This method-ology is in accordance with EIA-632 standard and based on the descriptionlanguage SysML. We have shown how the SysML model can be verified for-mally and by simulation, transforming the SysML model to HiLeS. HiLeSDesigner generates automatically a virtual prototype in VHDL-AMS whichis used, not only to verify the system model and its requirements, but alsoto find a physical solution that follows the behavior of the logical solution.

We show a clear tendency to rise the design level in embedded systemsusing the system level description, where there is not taken into account whichpart will be software and hardware. According to this tendency, the system issplit into functionality and components. The result of the mapping between


functionality and components is a system optimized following the systemtechnical requirements. Our methodology is strongly connected to achievea well-defined system design, reducing misunderstandings and verifying thedesign in each step of the system design process. This methodology coversthe system design from capturing requirements until the physical solutiondefinition. This approach based on the EIA-632 “building block” conceptmakes the hardware/software partition easier.

This work opens the path to add new SysML description diagrams such asActivity diagram which is more complete formalism than Sequence diagramto describe the behavior of the system or subsystems. Sequence diagram isused to describe the scenarios of the system, but it is limited to generalizethe behavior of the system deduced from the scenario. We think they arecomplemented and Activity diagram can be a next step in our methodology,after the sequence diagram, in the system behavior description.

We also propose to transform automatically the SysML model to HiLeSformalism using the MDA concept. We are developing HiLeS, SysML andVHDL-AMS metamodels (Albert et al, 2005) and also their transformationrules to build the basis of our transformation model. This automatic transfor-mation helps to verify quickly and without manual transformation mistakesthe system modeled in SysML.

We believe that HiLeS can be the execution environment for the SysMLmodel and also a good platform to formally verify the logical behavior ofa system using the Petri Net formalism included in HiLeS and to verify bysimulation generating a virtual prototype in VHDL-AMS. Once we have themodel in HiLeS, the details, which cannot be described in SysML, can bepossible using VHDL-AMS.

References

(1999) EIA-632 Processes for Engineering a System. Electronic IndustriesAlliance

(2005) 1220-IEEE Standard for Application and Management of the SystemsEngineering Process. IEEE

(2007) System Engineering Handbook Version 3.1. Interantional Council onSystems Engineering

(2010) International council on systems engineering (INCOSE). URLhttp://www.incose.org/

(2010) OMG Systems Modeling Language Specification Version 1.2. ObjectManagement Group

(2010) TOPCASED project. URL http://www.topcased.org/Abdurohman M, Kuspriyanto S, Sasongko A (2009) Transaction level mod-eling for early verification on embedded system design. International Con-


ference on Computer and Information Science (ICIS 2009), Washington,DC, USA, pp 277–282

Albert V, Nketsa A, Pascal JC (2005) Towards a metal-model based approachfor hierarchical petri net transformations to vhdl. Porto, Portugal, pp 531–536

Andrade E, Maciel P, Callou G, Nogueira B (2009) A methodology for map-ping SysML activity diagram to time Petri net for requirement validationof embedded real-time systems with energy constraints. In: Digital Society,2009. ICDS ’09. Third International Conference on, pp 266–271

Baker L, Clemente P, Cohen B, Permenter LPB, Pete S (2000) Foundationalconcepts for model driven system design. INCOSE Model Driven SystemDesign Interest Group

Berthomieu B, Vernadat F (2006) Time Petri nets analysis with TINA. ThirdInt. Conf. on The Quantitative Evaluation of Systems (QEST 2006), River-side, CA, USA, pp 123–124

Esteban P, Ouardani A, Paludetto M, Pascal JC (2005) A component basedapproach for system design and virtual prototyping. European ConcurrentEngineering Conference, Toulouse, France, p 8590

Estefan J (2009) MBSE methodology survey. Insight 12(4):16–18Gajski D, Abdi S, Gerstlauer A, Schirner G (2009) Embedded System Design.Springer

Gomez C, Pascal JC, Esteban P, Deleris Y, J-RDevatine (2010a) Embed-ded systems requirements verification using HiLeS designer. In: Real TimeSoftware and Systems 2010 (ERTS2 2010), Toulouse, France

Gomez C, Pascal JC, Jimenez F, Esteban P (2010b) Heterogeneous systemsverification on HiLeS designer tool. In: IECON 2010 - 36th Annual Con-ference on IEEE Industrial Electronics Society, Phoenix, USA

Gomez C, Pascal JC, Jimenez F, Esteban P (2010c) HiLeS Designer: A model-ing tool for embedded systems design validation. In: Production Research,5th Americas International Conference on, Bogota, Colombia

Hamon J (2005) Mthodes et outils de la conception amont pour les systmes etles microsystmes. PhD dissertation, Institut National Polytechnique, Ecoledoctorale de Gnie Electrique, Electronique, Tlcommunications, Toulouse,France

Hamon J, Esteve D, Pampagnin P (2004) High level system design usingHiLeS Designer. International Forum on Design Languages (FDL’04), Lille,France

Johnson T, Paredis C, Burkhart R (2008) Integrating models and simula-tions of continuous dynamics into SysML. In: Modelica’2008 InternationalConference on

Kawahara R, Nakamura H, Dotan D, Kirshin A, Sakairi T, Hirose S, Ono K,Ishikawa H (2009) Verification of embedded system’s specification usingcollaborative simulation of sysml and simulink models. In: Model-BasedSystems Engineering, 2009. MBSE ’09. International Conference on, pp21–28


Keutzer K, Newton A, Rabaey J, Sangiovanni-Vincentelli A (2000) System-level design: orthogonalization of concerns and platform-based design.Computer-Aided Design of Integrated Circuits and Systems, IEEE Trans-actions on 19(12):1523–1543

Martin J (2000) Processes for engineering a system: An overview of theansi/eia-632 standard and its heritage. Systems Engineering 3(1):1–26

Meservy T, Fenstermacher K (2005) Transforming software development: anmda road map. Computer 38(9):52–58

Morris T, Srivastava A, Reaves B, Pavurapu K, Abdelwahed S, Vaughn R,McGrew W, Dandass Y (2009) Engineering future cyber-physical energysystems: Challenges, research needs, and roadmap. pp 1–6

Nketsa A, Pascal JC, Anreu D, Esteban P (2004) Simulation and detectionof some properties of hybrid system based differential predicate-transitionpetri nets by means of vhdl-ams. Paris, France, pp 294–298

Ouardani A, Esteban P, Paludetto M, Pascal JC (2006) A meta-modelingapproach for sequence diagrams to Petri nets transformation within therequirements validation process. Toulouse, France, pp 345–349

Peak R, Burkhart R, Friedenthal S, Wilson M, Bajaj M, Kim I (2007a)Simulation-based design using SysMLpart 1: A parametrics primer. IN-COSE Intl. Symposium, San Diego, CA, USA

Peak R, Burkhart R, Friedenthal S, Wilson M, Bajaj M, Kim I (2007b)Simulation-based design using SysMLpart 2: Celebrating diversity by ex-ample. INCOSE Intl. Symposium, San Diego, CA, USA

Sangiovanni-Vincentelli A (2007) Quo vadis, sld? reasoning about the trendsand challenges of system level design. Proceedings of the IEEE 95(3):467–506

Sangiovanni-Vincentelli A (2008) Is a unified methodology for system-leveldesign possible? Design Test of Computers, IEEE 25(4):346–357

Shukla S, Pixley C, Smith G (2006) Guest editors introduction: The truestate of the art of ESL design. IEEE Design and Test of Computers pp335–337

Wagenhals L, Haider S, Levis A (2003) Synthesizing executable models ofobject oriented architectures. Systems Engineering 6(4):266–300

Weilkiens T (2008) Systems Engineering with SysML/UML Modeling, Anal-ysis, Design. Morgan Kaufmann Publishers

From Embedded Systems Requirements to Physical...

Documents

Transcript of From Embedded Systems Requirements to Physical...