Multi-aspect Virtual Integration approach forReal-Time and Safety Properties

Tayfun Gezgin, Raphael Weber, Markus OertelOFFIS Institute for Information TechnologyEscherweg 2, 26121 Oldenburg, Germany

{tayfun.gezgin, raphael.weber, markus.oertel}@offis.de

AbstractVerification techniques for analyzing the design orrequirements at early development stages are used since thebeginning of the model-based design paradigm. Most of theseanalyses are focused on a single purpose, like safety, real-time,or geometry. This separation of concerns leads to the introductionof so called aspects that describe these properties of a system.Nevertheless, these aspects are not necessarily independent. Inthis paper we use the fault tolerance time interval, the maximumtime to recover from faults, as an example to state the need for amulti-aspect analysis. We present how a virtual integration testcan be performed covering safety and real-time properties toprove the correct refinement of requirements. Our requirementsformalization approach using contracts, a pattern language andthe internal representation as timed automata are described. Thepresented technique is applied to an automotive lane-keeping-support system.

I. INTRODUCTION & RELATED WORK

For safety-critical systems a safety case is required thatproves the absence of unreasonable risks. Therefore, depend-ing on the applicable safety standards, a rather huge set ofanalysis activities needs to be performed. Typically, this in-cludes safety and timing analyses. These disciplines have beenseparated for a long time, finally leading to the establishmentof dedicated design aspects (views on the system) [1] whichare purely concerned with either safety or timing.

In practice, both aspects safety and real-time typicallycannot be regarded in isolation. For example, faults in anautomatic light controller of a vehicle need to be detected andmitigated in about 200ms. Therefore, changes in the safetyconcept may directly influence the timing requirements ofthe related components. Todays safety standards like the ISO26262 [2] put an early emphasis on both aspects, leading to aneed for combined analyses. As an example for the need of acombined analysis at an early stage of the development processis the concept of fault tolerance time intervals (FTTI) whichdefine the maximum time to mitigate a fault in the system,before it leads to a hazard. These requirements address bothaspects at the same time and are relevant from the initial hazardanalysis until the final development of software and hardware.

During the design process of a system the overall archi-tecture is typical refined in more fine-grained componentstructures. To avoid time intensive manual reviews, which haveto be performed over and over again in case of changes in thedesign, automated techniques have been proposed to analyzethe correct split-up of requirements. A popular technique is

called the virtual integration test (VIT, see Section IV) [3]which is able to prove whether a set of sub-requirementsfulfills a top-level requirement. The VIT uses contracts [4],[5] as a paradigm to enable component based black-boxintegration tests. The contract assertions are stated in a formallanguage. Simple to use languages have been proposed fortiming requirements [6] as well as for safety requirements [7].

Note that the aim of this paper is not to demonstrate ahigh performance multi-aspect analysis tool but to present anew method to combine both aspects, safety and real-time.Also note that we will not present a satisfaction analysis but amethod to check the validity of a virtual integration concerningthe specifications of components. We illustrate the usabilityand feasibility by applying our timed automaton based VITprototype implementation to an industrial case study with therestriction to permanent fault occurrences.

A. Related Work

Timing analyses were performed late in the developmentprocess, after the tasks and software architectures had beendefined, to give confidence in the chosen scheduling algorithmand the expected worst case execution times (WCETs). Inliterature there are many techniques to verify these properties.The classical approach for scheduling analysis is a holisticone, as it was worked out by e. g. Tindell and Clark [8]computing fixed-point equations of the whole architecture todetermine the response times of all allocated tasks. Mubeen etal. presented a tighter version of response time analysis withoffsets in [9] which is also implemented in the Rubus-ICE[10]. In [11] activation pattern for tasks are described by upperand lower arrival curves realizing a more compositional anal-ysis method. Based on this work a compositional schedulinganalysis tool, called SymTA/S, was created by SymtaVision[12]. These classical approaches typically yield pessimisticresults for systems containing distributed resources. Statebased techniques as presented in [13], [14] overcome thesedeficiencies coming along with a worse scalability. Anotherwork using a UPPAAL timed automata representation (likeour approach) derived from UML models is presented in [15].However, none of these approaches addresses safety aspects.

Safety analyses were mainly performed on higher abstrac-tion levels to prove the correctness of the safety concept.A classical approach concentrating on fault propagation areHipHops [16] to generate fault trees based on local propa-

gation specifications. In contrast to this approach, which canbe used together with development models like Simulink [17]also a couple of more theoretical safety analysis techniquesexist like function-structure models [18] or the commonlyused formalism of processes and channels [19]. However,none of the existing approaches is able to deal with real-timerequirements in a proper way.

For virtual integration testing also some tooling supportexists: A tool for checking the refinement between contractscalled OCRA was presented in [20]. There, contracts arespecified in a pattern based language called Othello whichare later translated to a temporal logic. In contrast to ourwork, they use an SMT solver to check such relations. Weuse a timed automaton approach as we also want to extendour approach by a schedulability check in future work.

B. Outline

In this paper we present an approach to formalize and ana-lyze (in a virtual integration setting) requirements addressingboth, safety and timing. In Section III we explain the necessityto combine safety and timing analyses on the example ofthe fault tolerance time interval. We present an extension ofthe pattern-based requirements specification language (RSL)to cover sporadic activations (representing sporadically oc-curring faults) and present a translation to timed automata inSection IV. We use a case-study of an lane-keeping-supportsystem to apply our technique in Section V, and finally givea conclusion and outlook for future work.

II. FUNDAMENTALS

This section provides an overview of basic notions and for-malisms necessary to understand how we realized the virtualintegration test. In our previous work [21] on a new commonsystems meta-model (CSM), Heterogeneous Rich Components(HRCs), which originate from the European SPEEDS project[22], represent the major modelling artifact. These HRCswill be explained in Subsection II-A. In addition to HRCsa methodology to traverse along the design space was alsoproposed in [21], a short outline of which is provided in Sub-section II-B. HRC requirements are specified in a formalizedway in the pattern based requirements specification language(RSL). An excerpt of the patterns relevant for this work isgiven in Subsection II-C. Finally, Subsection II-D contains aformal description of contracts to which we will refer in ourVIT approach (Section IV).

A. Heterogeneous Rich Components

The CSM provides basic building blocks needed to modelsystems as components with ports and connections (bindings)between them. We refer to these components as HeterogeneousRich Components (HRCs). HRCs rely on the basic conceptsof SysML blocks [23]. The dynamics of an HRC can bespecified by behavior, e. g. an external behavior model, oreven source code. Furthermore, requirements (or contracts)refer to a required behavior whereas the actual behavior isspecified as stated above. The idea of contracts is inspired by

Bertrand Meyers programming language Eiffel and its designby contract paradigm [24].

In HRC, contracts are a pair consisting of an assumptionand a guarantee, both of which are specified by some text.Here we assume that assumptions and guarantees are specifiedin RSL, see Subsection II-C. An assumption specifies howthe context of the component, i. e. the environment fromthe point of view of the component, should behave. Onlyif the assumption is fulfilled, the component will behave asguaranteed. This enables the verification of virtual system-integration (integrate a more detailed component or a sub-component in a more abstract environment) at an early stagein the design flow, even when there is no implementation yet.Thus, the system decomposition can be verified with respectto contracts. Contracts will be explained in more detail inSubsection II-D. Note that in this work we consider onlythe HRC semantics where a connection between two portsdescribes their equality. A deeper insight into HRCs can alsobe found in [25], [26].

B. Structuring the development process

When developing an embedded system, an architecture isregarded in different Perspectives at several Abstraction Levelsduring the design process as mentioned in Section I. Oneach abstraction level the product architecture is regardedin different perspectives. As an additional concept for theseparation of concerns, models in each perspective reflectdifferent aspects. For example, an aspect Safety might beregarded in every perspective but an aspect Real-Time isnot regarded in a geometric perspective and the aspect Costis not regarded when considering operational use cases.

To keep the models in different perspectives and abstractionlevels consistent (keep traceability between development steps)we defined a so called Realization- and Allocation-Link. Thebasic idea behind both concepts is to relate the observablebehavior of components exposed at its ports.

Realizations are relationships between ports of componentson different abstraction levels. Intuitively a realization-linkstates, that a component c1 has somehow been refined tocomponent c1 and is now more concrete in terms of itsinterface and/or behavior. The refinement cannot always becaptured by a pure decomposition approach. Thus, we definethe realization of a component by introducing a state-machinethat translates the behavior of the refined component c1 intoaccording events observable at a port of component c1.

Allocations are relationships between ports of componentsin different perspectives. Intuitively an allocation-link statesthat the logical behavior of a component c4 is part of thebehavior of a resource r2, to which it has been allocated. Here,we consider the same link-semantics as for the realization. Formore details, refer to [21]. In Section IV we will introduce atechnique to automatically verify the allocation and realizerelations of components.

As mentioned above, one basic design step is (de-) compo-sition. With contracts annotated to both the component and itssub-components, we want to check whether the composition

of the sub-components behavioral specifications is a validrefinement of the surrounding components behavior. Thefollowing section will describe a basic set of language patternsthat may be used to specify contracts.

C. Requirement Specification Language

Natural language requirements are often accompanied byambiguity, incompleteness or inconsistency; the reason forthis resides in the very nature of a spoken language. Theseunintended byproducts may not be detected until late phasesof the development process and therefore cause the realizationto not fulfill the intended goals of the specification or causeincompatibilities to other system parts. A solution to thisproblem would be the use of formal languages to specifythe requirements. But these are often hard to understand andtherefore difficult to use. An alternative that bridges this gap isthe pattern-based Requirements Specification Language (RSL)[27], [26]. This formal language provides a fixed semantic thatenables an automated validation or verification but is still wellreadable compared to natural language.

Consisting of static text elements and attributes which arefilled in by a requirements engineer, patterns have a well-defined semantic so that a consistent interpretation of thesystem specification between all stakeholders can be ensured.To cope with the needs of the different aspects of a design,various sets of patterns have been defined which are partlydescribed in the following. We thereby focus on the portionsrelevant for this work.

1) Basic Elements: We will shortly describe the basicelements (like events or time intervals) used in most patterns.

a) Events and Sets of Events: Events are signals thatoccur at a defined point in time. Examples are messages sentover a bus system, sporadic signals from sensors or even userinteraction like pressing a button. While specifying events thenames can be chosen by the requirements engineer, but haveto be used consistently, i. e. same events have to have the sameidentifiers. If there is an underlying architecture these nameshave to be mapped to the corresponding parts in the designmodel in later design stages.

b) Intervals: Intervals describe the amount of time be-tween two points in time. These points in time can eitherbe an event or a timed value. In case of events the firstoccurrence of the startevent opens the interval and the firstoccurrence of the endevent after startevent closes the interval:[startevent, endevent]. In case that timed valuesare the boundaries for an interval there must be referencepoint for the timers. The times in the action part refer to theactivation point of the pattern through the trigger. In that senseit is not allowed to use unbounded times values in the trigger.

c) Open/Closed Intervals: The braces for writing theintervals can be used to express open and closed intervals:

[a,b] closed, closed interval]a,b[ opened, opened interval

But also other combinations are possible:[a,b[ closed, opened interval]a,b] opened, closed interval

Closed intervals ends indicate that the point in time where theevent occurs still belongs to the interval, open interval endsindicate that the point in time at the events representing theborder does not belong to the interval.

2) R1 Pattern - Periodic Activation: event occurseach period [with jitter jitter]

This pattern describes the periodic occurrence of an eventsuch as the activation of a task. The event can be delayed byan additional jitter. This is a derived pattern from R2 such thatminperiod equals maxperiod. We restrict the jitter to be lessor equal than the period.

Example: Natural language requirement: The diagnosistask shall be executed every 10ms and may jitter 1ms.RSL: diagnosisTaskActivate occurs each 10mswith jitter 1ms.

3) R2 Pattern - Sporadic Activation: event occurssporadic with minperiod period [andmaxperiod period] [and jitter jitter].

This pattern describes the sporadic occurrence of an event.The minimal distance of the ideal occurrences is definedby minperiod, which can be delayed by an additional jitter.If maxperiod is given this specifies the maximal distancebetween the ideal occurrences. The minimal distance betweenthe real occurrences can be constrained by Pattern R3. As forthe R1 pattern, we restrict the jitter to be less or equal thanthe maxperiod.

Example: Natural language requirement: Processing of re-ceived data is necessary at most each 10ms and may jitter1ms. RSL: dataReceived occurs sporadic withminperiod 10ms and jitter 1ms.

4) R3 Pattern - Delay: Whenever event occurs,event [does not] occur[s] [duringinterval].

This pattern describes the dependency between two eventsthat may occur on different subjects. When using the optionalinterval attribute the pattern claims that the second eventoccurs in the specified time bounds. If no interval is specified,there is no constraint on when the event has to occur. In sucha case the requirement has to be refined later.

Example: Natural language requirement: The response timeof the diagnosis task shall be 10ms +/- 1ms. RSL: wheneverdiagTaskStart occurs, diagTaskFinishedoccurs during [9ms, 11ms].

D. Contracts

We use the pattern-based requirements specification lan-guage as described in Subsection II-C to specify contracts.For the analysis, the text patterns are transformed to timedautomata, as will be discussed in Section IV.

Formally, the semantics of a contract is defined as

[[C]] := [[A]]Cmpl [[G]], (1)

where (X)Cmpl defines the complement of a set X in someuniverse U , and [[X]] is defined as the semantic interpretationof X . In our case, [[X]] is given in terms of sets of timed traces.A trace over an alphabet is a sequence of events. Further,

a time sequence is a monotonically increasing sequence ofreal values, such that for each t R there exist some i 1such that i > t. A timed trace is a sequence (, ) where is a sequence of events and a time sequence. The set of alltimed traces over is denoted by Tr().

The specification S of a component is given in terms ofa set of contracts, i. e. [[S]] :=

ni=1[[Ci]]. An implementation

I of a component satisfies its specification S, if [[I]] [[S]]holds. The refinement relation between two contracts C andC is defined as follows:

C refines C, if [[A]] [[A]] and [[G]] [[G]], (2)

When a component is decomposed into a set of sub-components, we have to check whether the overall contractC = (A,G) (which also will be called global) and all subcon-tracts Ci = (Ai, Gi) (also called local) for i {1, ..., n} areconsistent. Under the assumption, that for all local assumptionsAi which have a non-empty intersection with the globalassumption A the subset relation Ai A holds, we have tocheck the following virtual integration condition:

i) A G1 ... Gn A1 ... Anii) A G1 ... Gn G.

(3)

An in-depth discussion about virtual integration can be foundin [3]. In [3] contracts were extended by so called weakassumptions. Weak assumptions are used to describe a setof possible environments in which the component guaranteesdifferent behaviors. This separation is only methodological,and does not affect the semantics of the definition of theoriginal contracts: Let C = (As, Aw1 , ..., Awn , G1, ..., Gn) bea contract consisting of a strong assumption As, a set of weakassumptions Awi , and a set of corresponding guarantees Gifor i N. Semantically, we map C to a standard contractof the form C = (As, G), where G = (G1 ... Gn)Gi = (Awi Gi).

III. FAULT TOLERANT TIME INTERVAL

The introduction of multiple design aspects was merelybased on the distinct types of analyses that have been per-formed to verify a system. Timing and Safety analyses arethe most popular aspects coming along a huge set of analysistechniques. Nevertheless, current safety standards like the ISO26262 [2] force a coalescence of these aspects. One argumentis the existence of the concept of Fault Tolerance TimeIntervals (FTTI) in both aspects, creating a close connection.

The FTTI specifies the time between the occurrence of afault and the hazardous event (see Fig. 1). The actual valueis given by the intended use of the item and its physicalenvironmental constraints. For example: during night drivingthe fault loss of both front lights has a FTTI from 10ms, i. e.within 10ms a proper reaction has to be performed to bringthe system back into a safe state. A possible safe state in thisexample could be switching on the fog- and side-lights. Whenthe 10ms are exceeded it might not be possible anymore forthe driver to keep the car on the road in any road situation.

Normal

Operation

Fault FaultDetection

Safe State

Possible

Hazard

TimeT

IV. VIRTUAL INTEGRATION CHECK USING TIMEDAUTOMATA

We will introduce a technique to check the refinement rela-tion of contracts in terms of the virtual integration condition asintroduced in Section II-D. For this, we translate all contractsof the corresponding system to UPPAAL timed automata [28],and perform a reachability check [29]. Our refinement checkwas initially introduced in [30].

i1

A: i1 occurs each 10msG: Whenever i1 occurs o1 occurs within [40,50]ms

System 1

i2

o1

o2

A: i2 occurs each 10msG: Whenever i2 occurs o2 occurs within [50,60]ms

Fig. 3. System with two independent contracts.

For our analysis, we assume that the specification of asystem or a component consists of either a single contract or aset of independent contracts that do not affect each other. LetS be a component, CS its contract specification, and P(C)the set of ports of S the contract C CS talks about. Weassume that for the contract specification of a system it holdsthat

CCS P(C) = . Consider for example the system

specification in Fig. 3, which consists of two contracts. Asboth contracts talk about different ports, they do not affecteach other, and thus can be treated independently from eachother. Checking dependent contracts would be much morecomplicated, as we would have to build the conjugation of alldependent contracts, involving negation parts in the formulae.A discussion for this can be found in [30]. Note that contractsbetween systems can have dependencies.

A. From Contracts to Automata Networks

Let (A,G) be a global contract, and let (Ai, Gi) for i {1, ..., n} be a set of local contracts. To check the condition ofEquation 3, we derive a timed automaton OAi out of each localassumption Ai for i {1, ..., n} serving as passive observer.Further, we derive a timed automaton OG out of the globalguarantee G. The transitions of each OAi for i {1, ..., n} andOG are annotated with receiving events and clock constraintsin such a way that the observers accept the set of timed traceswhich are element of [[Ai]] and [[G]]. For all traces which arenot element of [[Ai]] (or [[G]]) the corresponding observer entersa bad state.

Further, we derive an automaton TA for the global assump-tion A and automata Ti with i {1, ..., n} for each localguarantee. These automata serve as trigger for the observerautomata. The transitions of TA are annotated with sendingevents and timing constraints, such that TA produces all tracesthat are element of [[A]]. The automata for the local guaranteesconsist of both receiving and sending events (see next section

S0

z0

S0 S1

z0 period

event?z0 := 0

z0 > periodz0 := 0

z0

0

1

2

3

4

5

6

7

8

0 100 200 300 400 500 600 700

d [ms]

mD [

Nm

]

Recognizable

Disturbing

Uncontrollable

Fig. 7. Controllability of deviations in power steering systems [33].

case specifying the maximum time a fault may be presentin the system unless the hazard occurs, the Fault ToleranceTime Interval (FTTI). This high level timing requirementis further refined during the development process. The ISO26262 requires an analysis assuring this refinement has beenperformed correctly, making the virtual integration check avaluable tool for safety engineers.

We modeled the LKS using the CSM. The LKS-modelintroduced in [34] thereby served as a basis. The overallfunctional structure of the LKS system is displayed in Fig. 8.The functional chain starts at the video sensing unit whichproduces an uncompressed 2 mega-pixel 15 frames per sec-ond video stream. This video stream is used to extract lineinformation which may indicate lanes of a street, so the dataworkload between video sensing and line detection is quitehigh. From there, rather small data amounts are passed downthe chain. Line-to-lane-fusion extracts the actual data aboutthe own and the neighboring lanes relevant for the car fromthe line data passed down from line detection. As the namesuggests, the situation evaluation assesses the current situationbased on additional sensor data (i. e. the current steeringangle and other human machine interface data) and outputsthe (un)intended trajectory as indicated by the sensor data.Additionally, situation evaluation forwards data about whetherthe trajectory is intended or unintended based on certainthresholds in the sensor data analysis. The trajectory planningfunction is the controlling part that compares the trajectoryfrom the situation evaluation with the current trajectory of thecar (analyzed using a yaw-rate sensor as source). Based onthe offset between these two trajectories and the informationabout the intention of the driver it decides when and how tointervene. After the trajectory planning there is a breakdownin different options, depending on which hardware is actuallyused in the system (either ESP or EPS; neither ESP nor EPS;both ESP and EPS). In our case study we considered the latter.

Starting with this functional structure of the LKS systemwe refined our model by adding communication signals be-tween the functions and deriving a logical structure from the

Video Sensing

Line DetectionLine-to-Lane

Fusion

Situation

Evaluation

Trajectory

Planning

Braking

Intervention

Steering

Intervention

Braking

Actuators

Steering

Actuators

HMI Yawrate SensingSteering Angle

ESP

(stability program)

EPS

(power steering)

Fig. 8. Functional structure of the LKS case study.

functional one. Note that some signals are forwarded (i. e.connected) to multiple logical tasks (logical units performingcalculations). The distinction between tasks and signals is anecessary refinement step to emphasize that communicationinduces behavior and thus takes time. This is of particularimportance for the virtual integration test since the composi-tion of signals and tasks along with their allocation to busesand processing units impacts the overall timing behavior. Notethat we do not analyze the schedulability for allocated tasksand signals to buses and processing units in this paper. Weonly consider the systems specifications and its subsequentrefinements in this work. In the following two subsections wedescribe the safety and timing specifications for the SituationEvaluation task in both the black-box and the white-box view.

A. Black-Box View of Situation Evaluation

The Situation Evaluation (SE) is concerned with assessingthe current car situation. It calculates the currently set trajec-tory of the car based on the steering angle sensor input andthe lane information. Additionally, it receives data from thehuman machine interface upon which it decides whether thedriver steered intentionally or not.

LogicalTask

SituationEvaluation

lane_data

driver_intentionsteering_angle

hmi_data

set_trajectory

fault

Contract_FTTI

As: fault occurs sporadic with minperiod 100ms and maxperiod 10000h.

G: whenever fault occurs, driver_intention=true occurs during [0ms,40ms].

wd_activation

Contract_SE_RT

As: hmi_data && steering_angle occurs each 20ms;

wd_activation occurs each 15ms;

Aw: fault=false.

G: whenever hmi_data && steering_angle occurs, driver_intention &&

set_trajectory occurs during [10ms,20ms].

Satisfy

Satisfy

Fig. 9. Black-box view of the situation evaluation task.

Fig. 9 shows the black-box view of the SE task whichsatisfies the contract Contract FTTI specified as follows:Assuming that a fault (re)occurs within certain time bounds(between 100 milliseconds and 10, 000 hours) SE shall guar-antee that within 40ms SE returns to a safe state (in this case:make sure that the LKS does not override the driver, i. e. it isthe drivers intention to steer with the given steering angle).The guarantee part reflects the FTTI, derived from a previouslyperformed safety analysis. The other contract Contract SE RTspecifies the real-time behavior of SE. Here we assume thathmi data and steering angle are events that always occurtogether and trigger the SE task every 20ms. Furthermore, weassume that the internal fault detection mechanism is triggeredevery 15ms. With the weak assumption we ensure that we onlyhave to ensure the guarantee if there is no fault. The guaranteeof that contract states that the delay between triggering andanswering shall be between 10ms and 20ms.

B. White-Box View of Situation Evaluation

The white-box view of the SE task gives more detail on thesingle sub-tasks and reveals the internal safety mechanisms. InFig. 10 we see the sub-tasks and their requirements. The safetyrelevance of the system has already been discussed, leadingto a need for architectures able to detect and mitigate faults.To reduce the complexity, we just focus on one single fault inthe SE component: a permanent crash of the SECalculationsub-task. Faults are modeled as additional ports, where asignal may arrive sporadically between 100ms and 10, 000h,representing the occurrence of the fault. In the implementationwe currently make sure that all faults are permanent, i. e.once they occurred they cannot disappear on their own. Tobe able to detect this fault a watchdog is used, which isactivated every 15ms. Right after its activation it sends arequest to the SECalculation unit and waits for a response.If the SECalculation is not responding the component isconsidered broken and the faulDetected port is set to true.

The SEFaultReact sub-task is a typical override componentthat replaces the signals coming from the SECalculation sub-task by the safe-state if the component is faulty. Consideringthat we want to avoid that the whole system causes a steeringangle correction without need, the safe-state is given by settingthe driver intention signal to true. The following componentswill not try to attempt a correction. In addition, the driverneeds to be informed about the reduced functionality until itmay be resolved by a reset. Driver warning and reset mecha-nisms are not modeled here to keep the example readable.

There are two contracts for the calculation routine in the bot-tom of the figure specifying the real-time property of a dead-line in Contract SECalculation RT and the watchdog behav-ior in the fault-free case in Contract SECalculation NoFault.The calculation task offers two additional ports req and ackto allow for the watchdog-based fault recognition.

In the upper part of the figure there are two con-tracts each for both SEWatchDog and SEFaultReact. Con-tract FautlDetection and Contract AllOK specify how thefault is detected by the watchdog and which corresponding

LogicalTask

SituationEvaluation

LogicalTask

SEWatchDog

lane_data

steering_angle

fault

LogicalTask

SECalculation

di

hmi_data

LogicalTask

SEFaultReact

faultDetected

driv

er_

inte

ntio

n

Contract_FaultReact

Aw: di occurs each 20ms; faultDetected=false.

G: whenever di occurs, driver_intention

occurs during [1ms,2ms].

di

req

ackwd_activation

Contract_SECalculation_RT

As: hmi_data && steering_angle occurs each 20ms;

req occurs each 15ms.

G: whenever hmi_data && steering_angle occurs,

di && set_trajectory occurs during [10ms,12ms[.

Contract_SECalculation_NoFault

As: fault occurs sporadic with minperiod 100ms and maxperiod 10000h.

Aw: fault does not occur during [0ms,10ms[.

G: whenever req occurs, ack occurs during [10ms,12ms[.

Satisfy

set_trajectory

Contract_FaultReact_SafeState

G: whenever faultDetected=true occurs,

driver_intention=true occurs during

[1ms,2ms].

Contract_FaultDetection

As: wd_activation occurs each 15ms.

Aw: whenever req occurs, ack does not

occur during [10ms,12ms[.

G: whenever wd_activation occurs,

faultDetected=true occurs during

[10ms,15ms].

SatisfyContract_AllOK

Aw: whenever req occurs,

ack occurs during [10ms,12ms[.

G: whenver wd_activation occurs,

faultDetected=false occurs during

[10ms,15ms].

Satisfy

Fig. 10. White-box view of the situation evaluation task.

output events are sent to the fault reaction component. Notethat we assumed here that the wd activation and the req arethe same signal (i. e. a req is sent by the watchdog immediatelyafter it has been activated).

Contract FaultReact specifies the required real-time delaybetween the triggering of SEFaultReact by the di event and thedriver intention event. Contract FaultReact SafeState statesthat if a fault is detected (indicated by the signal received fromthe watchdog) the safe state shall be reached within 1ms to2ms. As mentioned above safe state means that we make surethat the LKS does not interfere with the drivers commands.

C. Verification

To check the decomposition of our case study we applyand adapt the transformation of the considered RSL pat-terns illustrated in Section IV and our corresponding pro-totype implementation. To obtain independent contracts asdiscussed in Section IV for the use case scenario, we con-sider that the evaluations of the ports driver intention=false,driver intention=true, faultDetect=true, and faultDetect=falseare all different events, and rename driver intention=true tosafeState, driver intention=false to ok, faultDetect=true tofalutDetection, and faultDetect=false to noFault. Our systemmodel assumes that sporadically there could occur a fault.We are restricted to use 15-bit integers through the usage ofUPPAAL. In the use case scenario, the upper bound of thesporadic activation of the fault was specified as 10, 000h. Forthe generated automaton we use the maximum allowed value

32767. This makes no difference, as the value is still muchlarger than the defined delay times.

Our prototype implementation builds a trigger automa-ton out of all assumptions of the overall SituationEvalua-tion component as illustrated in Section IV, specifying thatevents hmi data and steering angle occur periodically withthe period value 20, and that event fault occurs sporadicallywithin the interval [100, 32767]. Further, the tool derivesa pure observer automaton OGSE RT out of the guaranteeof the SituationEvaluation component, specifying a globaldeadline between the occurrence of the events hmi data,driver intention and steering angle, set trajectory. Further,the FTTI is specified to be between [0, 40] time units leadingto the observer automaton OGFTTI .

bad

S0 S1

reset_1?

a_w1!

ack?

z0 >= ubz0:=0

wd_activation_1?z0:=0

wd_activation_1?

lb

still need to integrate more concepts from the safety perspec-tive: We are currently limited to permanent faults, leavingtransient ones aside. Additionally, we focused on crash asa single fault type, which leads to a situation in which theaffected component may not react at all anymore. This scopeneeds to be extended to also include other fault types. Adelay, causing a violation of timing requirements is a straightforward extension, as well as the introduction of value faults,causing calculations to produce wrong results. The combinedspecification of safety and timing requirements may be usedfor other analyses than virtual integration. Depending on theoverall load of the controller, on which the presented watchdog of the system runs, the fault detection time may vary.To verify these times, we will apply our scheduling analysistechnique [35].

ACKNOWLEDGMENTThis work was partly supported by the European Com-

mission funding the Large-scale integrating project (IP) pro-posal under ICT Call 7 (FP7-ICT-2011-7) Designing forAdaptability and evolutioN in System of systems Engineering(DANSE) (No. 287716), the German Federal Ministry ofEducation and Research under grant number 01IS12005M,the ARTEMIS Joint Undertaking within the European projectMBAT under grant agreement No. 269335, the German FederalMinistry of Education and Research (BMBF) under grantnumber 01IS11003L. The responsibility for the content of thispublication lies with the authors.

REFERENCES[1] I.-S. S. B. IEEE Std 1471-2000, Ieee recommended practice for archi-

tectural description of software-intensive systems, September 2000.[2] ISO26262, Road vehicles functional safety, 2011.[3] W. Damm, H. Hungar, B. Josko, T. Peikenkamp, and I. Stierand, Using

contract-based component specifications for virtual integration testingand architecture design, in DATE Exhibition, 2011, pp. 16.

[4] A. Benveniste, B. Caillaud, A. Ferrari, L. Mangeruca, R. Passerone,and C. Sofronis, Multiple viewpoint contract-based specification anddesign, in Formal Methods for Components and Objects. SpringerBerlin Heidelberg, 2008, vol. 5382, pp. 200225.

[5] A. Benveniste, B. Caillaud, D. Nickovic, R. Passerone, J.-B. Raclet,P. Reinkemeier, A. Sangiovanni-Vincentelli, W. Damm, T. Henzinger,and K. Larsen, Contracts for systems design, in Inria Research, 2012.

[6] P. Reinkemeier, I. Stierand, and P. R. S. Henkler, A pattern-basedrequirement specification language: Mapping automotive specific timingrequirements, in Software Engineering 2011 Workshopband, R. Reuss-ner, A. Pretschner, and S. Jhnichen, Eds. Gesellschaft fur Informatike.V. (GI), 2011, pp. 99108.

[7] M. Oertel, A. Mahdi, E. Bode, and A. Rettberg, Contract-based safety:Specification and application guidelines, in Proceedings of the 1stInternational Workshop on Emerging Ideas and Trends in Engineeringof Cyber-Physical Systems (EITEC 2014), 2014.

[8] K. Tindell and J. Clark, Holistic schedulability analysis for distributedhard real-time systems, Microprocess. Microprogram., vol. 40, pp. 117134, April 1994.

[9] S. Mubeen, J. Maki-Turja, and M. Sjodin, Support for end-to-endresponse-time and delay analysis in the industrial tool suite: Issues,experiences and a case study, Comput. Sci. Inf. Syst., vol. 10, no. 1, pp.453482, 2013.

[10] J. Maki-Turja and M. Nolin, Efficient implementation of tight response-times fortasks with offsets, Real-Time Systems, vol. 40, no. 1, pp. 77116, 2008.

[11] L. Thiele, S. Chakraborty, M. Gries, A. Maxiaguine, and J. Greutert,Embedded software in network processors - models and algorithms.Springer Verlag London, UK, 2001, pp. 416 434.

[12] R. Henia, A. Hamann, M. Jersak, R. Racu, K. Richter, and R. Ernst,System level performance analysis - the symta/s approach, Computersand Digital Techniques, IEE Proceedings -, vol. 152, no. 2, pp. 148166,Mar 2005.

[13] E. Fersman, P. Pettersson, and W. Yi, Timed automata with asyn-chronous processes: schedulability and decidability, in Proceedings ofTACAS. Springer, 2002.

[14] A. David, J. Illum, K. G. Larsen, and A. Skou, Model-based frameworkfor schedulability analysis using uppaal 4.1, in Model-Based Design forEmbedded Systems, G. Nicolescu and P. Mosterman, Eds., 2009.

[15] A. Muniz, A. Andrade, and G. Lima, Integrating uml and uppaal for de-signing, specifying and verifying component-based real-time systems,Innovations in Systems and Software Engineering, vol. 6, no. 1-2, pp.2937, 2010.

[16] A. Pasquini, Y. Papadopoulos, and J. McDermid, Hierarchically per-formed hazard origin and propagation studies, in Computer Safety,Reliability and Security, ser. Lecture Notes in Computer Science,K. Kanoun, Ed. Springer Berlin / Heidelberg, 1999, vol. 1698, pp.688688, 10.1007/3-540-48249-0 13.

[17] Y. Papadopoulos and M. Maruhn, Model-based synthesis of fault treesfrom matlab-simulink models, in Dependable Systems and Networks,2001. DSN 2001. International Conference on, 2001, pp. 7782.

[18] K. Echtle, Fehlertoleranzverfahren. Springer-Verlag, 1990.[19] L. Lamport and S. Merz, Specifying and verifying fault-tolerant sys-

tems, in Formal Techniques in real-time and fault-tolerant systems.Springer, 1994, pp. 4176.

[20] A. Cimatti, M. Dorigatti, and S. Tonetta, Ocra: A tool for checking therefinement of temporal contracts, in ASE IEEE, 2013, pp. 702705.

[21] A. Baumgart, P. Reinkemeier, A. Rettberg, I. Stierand, E. Thaden,and R. Weber, A model-based design methodology with contractsto enhance the development process of safety-critical systems, inProceedings of the 8th IFIP WG 10.2 international conference on Soft-ware technologies for embedded and ubiquitous systems, ser. SEUS10.Berlin, Heidelberg: Springer-Verlag, 2010, pp. 5970.

[22] The SPEEDS Consortium, SPEEDS Project, http://speeds.eu.com.[23] OMG Systems Modeling Language (OMG SysML TM), Object Manage-

ment Group, November 2008, version 1.1.[24] B. Meyer, Applying design by contract, Computer, vol. 25, no. 10,

pp. 4051, 1992.[25] B. Josko, Q. Ma, and A. Metzner, Designing Embedded Systems using

Heterogeneous Rich Components, Proceedings of the INCOSE, 2008.[26] Project SPEEDS: WP.2.1 Partners, SPEEDS Meta-model Behavioural

Semantics Complement do D.2.1.c, The SPEEDS consortium, Tech.Rep., 2007.

[27] P. Reinkemeier, I. Stierand, P. Rehkop, and S. Henkler, A pattern-basedrequirement specification language: Mapping automotive specific timingrequirements, in Software Engineering 2011 - Workshopband, ser. LNI.GI, 2011.

[28] K. G. Larsen, P. Pettersson, and W. Yi, Uppaal in a nutshell, Interna-tional Journal on Software Tools for Technology Transfer STTT, vol. 1,no. 1-2, pp. 134152, 1997.

[29] L. Aceto, A. Burgueno, and K. Larsen, Model checking via reachabilitytesting for timed automata, in Tools and Algorithms for the Constructionand Analysis of Systems, ser. Lecture Notes in Computer Science,B. Steffen, Ed. Springer Berlin / Heidelberg, 1998, vol. 1384, pp.263280, 10.1007/BFb0054177.

[30] T. Gezgin, R. Weber, and M. Girod, A refinement checking tech-nique for contractbased architecture designs, in Fourth InternationalWorkshop on Model Based Architecting and Construction of EmbeddedSystems, 10 2011.

[31] L. Thiele, S. Chakraborty, and M. Naedele, Real-time calculus forscheduling hard real-time systems, in IEEE International Symposiumon Circuits and Systems (ISCAS), vol. 4, 2000, pp. 101 104 vol.4.

[32] G. Reimann, P. Brenner, and H. Buring, Handbuch Fahrerassistenzsys-teme. ViewegTeubner Verl, 2012, ch. Lenkstellsysteme, pp. 287 311.

[33] M. Suerken and T. Peikenkamp, Model-based application of iso 26262:The hazard and risk assessment, SAE, Tech. Rep., April 2013.

[34] R. Weber, E. Thaden, S. Henkler, J. Hofflinger, and S. Prochnow,Design space exploration for an industrial lane-keeping-support casestudy, in Proceedings of DATE Conference University Booth, 24 -28 Mar. 2014.

[35] T. Gezgin, I. Stierand, S. Henkler, and A. Rettberg, State-based schedul-ing analysis for distributed real-time systems, Design Automation forEmb.Sys., pp. 118, 2013.

Introduction & Related WorkRelated WorkOutline

FundamentalsHeterogeneous Rich ComponentsStructuring the development processRequirement Specification LanguageBasic ElementsR1 Pattern - Periodic ActivationR2 Pattern - Sporadic ActivationR3 Pattern - Delay

Contracts

Fault Tolerant Time IntervalVirtual Integration Check using Timed AutomataFrom Contracts to Automata NetworksFrom Pattern to Timed Automata

Case StudyBlack-Box View of Situation EvaluationWhite-Box View of Situation EvaluationVerification

Conclusion & OutlookReferences