adding value to automotive models - Semantic Scholar · PDF file ·...

Adding Value to Automotive Models

Eckard Bode1, Werner Damm1, Jarl Høyem1,Bernhard Josko1, Jurgen Niehaus2, and Marc Segelken1

1 Kuratorium OFFIS e.V. Safety Critical Systems, Escherweg 2,26121 Oldenburg, Germany

{boede, damm, hoyem, josko, segelken}@offis.dehttp://www.offis.de/

2 Carl von Ossietzky University OldenburgAmmerlander Heerstr. 114-118, D-26129 Oldenburg, Germany

[email protected]

http://ses.informatik.uni-oldenburg.de/

Abstract. We report on how implementing a Model Based AutomotiveSW Engineering Process in an industrial setting can ensure the correct-ness of automotive applications when a process based on formal modelsis used. We show how formal methods, in particular model checking, canbe used to ensure consistency of the models and can prove that the mod-els satisfy selected functional and safety requirements. The techniquecan also be used to automatically generate test vectors from the model.Hence we show how in many ways formal verification techniques can addvalue to the models used for different purposes in developing automotiveapplications.

1 Introduction

Figure 1 taken from a public presentation3 of Dr. Frischkorn, Head of ElectronicSystem Development, BMW Group, shows the exponential growth in electroniccomponents in cars, spanning all segments from power train, body electronics,active and passive safety, as well as navigation and infotainment. Today, up to40% of the total vehicle cost originate from the cost of electronic components,with 50-70% of this share taken by embedded software development. The keystrategic role of electronic components in cars is expected to expand - 90% of allinnovations are driven by electronic components and software.

This exponential increase in functionality comes together with two othersources of complexity: increasingly one function is shared across multiple elec-tronic control units (ECUs), i.e. it requires the correct and timely interactionof multiple sub-functions distributed over multiple ECUs. Such distributed hardreal-time systems contrast drastically in complexity with the typically singleECU based technologies, for which electronic design processes in place todaywhere optimized, and lead directly to complex interfaces between OEMs and

3 ARTIST and NSF Workshop on Automotive Software Development, San Diego,USA, Jan 2004.

2 Werner Damm et al.

© O

SC

Em

bedd

ed

Sys

tem

s −

all

right

sre

serv

ed−

CO

NFI

DEN

TIA

L

5

Fig. 1. Automotive Software - An Emerging Domain

multiple suppliers (in contrast to the traditional situation where one supplierused to provide a complete solution). Finally, the introduction of new tech-nologies such as X-by-wire (e.g. ”brake-by-wire”, such as needed for fully au-tomatic distance control), mandate introductions of new technologies (such astime-triggered architectures), for which there is no established design practicetoday.

Jointly, these drastic changes in the development of electronic automotivecomponents have lead to an increased level of failures of electronic components,sometimes making headlines news4. As recently reported in ”Die Welt”5, Ger-many has seen 940 000 cars impacted by call-back actions. The German Auto-motive Club ADAC reports, that 50 % of all failures treated where due to failurein electronic components.

Multiple lines of attack have been launched by the automotive industry tocounter such developments. In particular, there is an increasing trend towardsso-called model-based development, in which the largely textual way of require-

4 Spiegel On-Line reported in May 12, 2003, that the finance minister of Thailand wascaught in his BMW due to a failure of the central locking system, further impairedby a failing climate control system. PC magazine reported in January 2001, thatFord has acknowledged a software bug in the cruise control chip, causing the car todash backwards when entering reverse.

5 Die Welt, 15.1.2004

Adding Value to Automotive Models 3

ment capturing, still wide-spread today, is replaced by the creation of executable

specification models, often referred to as model-based development.

Companies have adopted various use cases to capitalize on such specificationmodels. For OEMs, typical use cases include virtual system integration (allowingto simulate the distributed realization of automotive functions prior to contract-ing suppliers for the development of sub-functions), concept validation for indi-vidual sub-functions, assuring that the required functionality can be realized,and the use of specification models as a basis of contracts with suppliers. Typi-cal use-cases on the supplier side include concept validation and automatic codegeneration, where production quality C-code is automatically generated fromspecification models.

Such model-based processes allow a significant improvement of design quality,but fail to address the testing gap - classical approaches to testing fail in beingadaptable to the drastic changes in the development of electronic automotivecomponents for inherent reasons. Classical approaches to testing are guided bythe test-engineers intuition and experience in designing ”good” test cases, testcases, which have a high likelihood in exposing errors. Typically, in the classicalsetting, each ECU development team will have at least - depending on the size ofthe ECU - one test-engineer, who - on the basis of textual requirement documents- is responsible for designing test cases for acceptance testing (of ECUs deliveredby the supplier) and integration testing. Ideally, test cases cover all functionality,address boundary conditions, are designed to expose typical design faults, andshould cover the code running in ECU completely.

The exponential increase in complexity, and the increasingly distributed na-ture of functions, render the manual construction of good test cases impossible.It is a simple exercise to calculate the number and width of test vectors neededto cover today’s ECUs. A typical body electronic control unit would have aninterface to one or two CAN-bus systems, as well as a number of sensors andactuators directly connected to the ECU. At the bit level representation used indigital processing, this amounts to a typical width of between 50 to 1000 signals.Internally, specification models to such ECUs would typically have some 10 to30 sub-functions, each with about 20 to 100 key states. Since these state ma-chines run in parallel, this gives in the order of 5020 possible state combinations,further compounded by the fact, that state transitions will typically depend onaround another 50 or so internal variables of the controller, which use fixed-pointor floating point representations to represent computational objects like brakepressure, acceleration, speed, RPMs, etc. The total number of possible situationsof such a specification model exceeds the number of atoms in the universe.

It is this sheer astronomical complexity, which in quantitative terms expressesthe testing gap - it is simply impossible even for the most qualified test-engineerto come up with good test cases. The challenging question is, how in this junglecan he ever hope to find those critical scenarios, which expose the designerserrors - and these are bound to be there.

This paper describes three approaches addressing the testing gap, all au-tomating test-generation in different, use-case specific ways. All test-automation


solutions are based on techniques for automatic exploration of extremely largestate-spaces, which capitalize on leading edge research results and extensive in-dustrial experience in the usage of this technology.

Both the model-checking and model-certification technologies offer 100% cov-

erage of specification models in detecting potential violations of style guides orrequirements. The model-checker is optimized for ease of use and fast turn-around times, thus aiming at supporting the typical engineer developing a par-ticular application, or even the integration of multiple functions in a single ECU.The model-checker allows to invoke automatic compliance tests for style-guides,such as enforcing that specification models are free of racing conditions or non-determinism. It supports the designer in posing queries of the kind ”can I reachstate unlock while at the same time issuing a command to lock” (as could be rel-evant for a central locking system), or to check, whether a specific combinationof actuators settings can be achieved. Results of such queries are maintained in adata-base, and can thus be used for regression testing. The model-certifier aimsat test-engineers or safety engineers, and supports the certification of full ECUspecification models against functional, safety, or real-time requirements, suchas ”upon detecting a crash, the side airbag will be unfolded within 5 ms”, or”the steering wheel will never be locked, when ignition is on”. Both are relyingon techniques which explore all possible execution scenarios, taking into accountall possible readings of interface objects, e.g. all possible CAN-bus messages, orall possible sensor readings - and this over an unbounded run-time. They thusattack the testing gap by automatically exercising all possible paths through thespecification model - whereas each manually specified test-case would only ad-dress a single path. A key enabler of industrial usage of these techniques restsin the ability to fully automate this process - this in spite of the complexity oftoday’s electronic components6.

The second technology variant, aiming at the automatic generation of test

vectors, bridges the gap between specification models and implementation, bygenerating executable test sequences, which can be used for Software-in-the-loopor Hardware-in-the-Loop testing. Driven by user-selected coverage criteria, suchas covering all states, all transitions, all guards, toggling all outputs, etc, test-vectors are automatically generated from specification models. This variant isaddressing the key use-case of acceptance testing - such as checking, whether anECU delivered by a supplier is conformant to a specification model - an ECUwill only be accepted, if it reacts to all stimuli provided in the test-vectors withthe responses also prescribed in the automatically generated test-vectors. Thereis vast body of industrial experience in the generation of test-cases7.

The third technology variant addresses fault-tree analysis, using state explo-ration techniques for specification models into which faults have been injectedaccording to relevant models to automatically construct a fault-tree character-

6 As an example, the total certification time of 36 safety requirements for an Airbagmodel was below 30 minutes.

7 Generation time of test-vectors achieving high model-coverage ranges from hours todays for full ECU specification models.


izing all possible ways how injected faults can lead to a given top-level event.This method would typically be applied after having used the model-certifier, i.e.after having demonstrated that under nominal behavior all safety requirementsare satisfied.

The technologies have been fully integrated with a range of tools in indus-trial usage today for developing specification models, including ASCET-SD [1]from ETAS, Matlab-Simulink/Stateflow from The MathWorks, Statemate andRhapsody from I-Logix, and Scade [2] from Esterel Technologies. All tool namesare tradmarks of the respective companies. We consider this integration of theunderlying methods with industry standard CASE tools to be a prerequisite forthe introduction of such methods into the industrial design process for electroniccontrol units. This paper will de-emphasize the chosen lines of attach for inte-gration COTS development tools with the underlying mathematical algorithms- we refer the reader to papers cited above for examples of the chosen integrationapproaches.

1.1 Related Work and the Formal Verification Road map

Formal Verification allows designers to mathematically prove functional, real-time, and safety properties of subsystem or ECU models. Requirements thatcan be proven include

– functional properties: Whenever input i occurs, output o is produced.

– real-time properties: Whenever input i occurs, output o is produced within5 milliseconds.

– safety properties: The system will never enter an error state.

– liveness properties: The system will not deadlock.

The application of formal methods to the development of safety critical sys-tems has been a driving factor in promoting research. This is reflected in variousconference series on formal methods and verification techniques (such as Formal

Methods Europe, CAV, TACAS, FMCAD), conferences on real-time systems suchas FTRTFT (Formal Techniques in Real-Time and Fault-Tolerant Systems), andHybrid Systems such as the HCCS conference series, and Journals such as theJournal on Formal Methods in System Design.

During the last decade, formal verification techniques, like model checking(cf. [3]) or theorem proving (cf. PVS [4], Isabelle [5], etc.), have been pushedby researchers from the CAV and Hybrid Systems community (e. g., [6], [7]) toincrease both, the level of complexity of systems and the class of models amenablefor automatic formal verification. Today, automatic verification techniques arefurther developed in a wide variety of research projects, e. g., PATH8, MoBIES9,

8 see www-path.eecs.berkely.edu9 see www.rl.af.mil/tech/programs/MoBIES


SafeAir10, Omega11, AVACS12, and Verisoft13, as well as being used in industrialdesign processes (cf. [8]).

To cope with full ECU models, these techniques combine a range of analy-sis engines like Binary Decision Diagrams (BDDs, [9, 10]), satisfiability checkers(SAT, [11, 12]), constraint solvers ([13, 14]), decision procedures ([15, 16]), lin-ear programming ([17]), abstraction refinement ([18, 19]), predicate abstraction([20, 21]), etc. Current trends in development will result in a further increase ofautomation especially for the verification of hybrid systems ([22]) as well as asemantic integration with industry standard CASE tools to enable their integra-tion into industrial design flows (see below).

2 Model Based Design

In the SafeAir project the goal was to improve the V based development pro-cess to save development time and effort while preserving or improving the de-pendability of the developed systems. The implementation methodology thatis developed in SafeAir increases the understandability and correctness of therequirements, the correctness of the design and the code with respect to therequirements. The emphasis within the project was on formal development ofsystems, providing formal specification, model checking technology, automatictest case generation and validated code generation.

The semantic integration of system-level and design-level modeling tools al-lows a virtually integrated V-process that is sharpened up to a Y-based processwith the required steps at the bottom of the former V being considerably auto-mated. See figure 2.

Automatic code generation for the complete integrated system with a certi-fied code generator complying to the DO178B standard eliminates manual codegeneration and integration as well as unit testing on the Code level. Formal ver-ification partially supersedes testing by proving the correctness of the design atmultiple levels ranging from subcomponents for creating golden devices up to theoverall virtually integrated system. Technically using the generated C code forverification, even formal verification of the target C code is possible, though notrequired since code generation can always be automatically validated if needed.For a certain C compiler automatic code validation can even be applied to the bi-nary representation, proving the correctness of each translation. Remaining testcases not covered by verification or validation are finally addressed by automaticgeneration of test cases, which could additionally be used to fortify verificationresults.

The modeling tools being integrated in SafeAir are Statemate, Simulink /Stateflow, SCADE and Sildex, with the latter two constituting the possible inte-gration platforms being able to import any of the formats mentioned, enabling

10 see www.safeair.org11 see www.omega.imag.fr12 see www.avacs.org13 see www.versoft.de


http: //www.safeair.org

System (supplier)

Equipment(manufacturer)

detailed Design

global design

Software specification

SystemSpecification

VY

Optimized−Y

State of the art

DO178Bcompliance

Advanced users

Improved−Y

Fig. 2. Improving V based processes - lessons from SafeAir. Diagram by Mr. Pilarski,Airbus France

the use of best-in-class problem-specific COTS modeling tools for central aspectssuch as control law design or architectural design. See figure 3.

Simulink

Stateflow

C code C code

Formal VerificationOf Hybrid Models

C code

Fig. 3. Integration of Modeling Tools in SafeAir

The integration is realized by gateways that translate models from the variousformats to semantically equivalent representations in either SCADE or Sildex.For Statemate the translation to SCADE is integrated in the Statemate tool andeven an interface for co-simulation is available.

Apart from the possibility to verify models with respect to their SCADErepresentation, OFFIS is able to verify models in each language representation


also either directly or by using a C code generator shipped with or dedicatedto the specific CASE tools. For example Stateflow verification through the Tar-getLink code generator was realized outside the SafeAir project in cooperationwith DaimlerChrysler.

The application cases have demonstrated that this new methodology shouldsignificantly reduce the risk of design errors and shorten the overall design cyclecompared to a traditional development.

The project demonstrated that the goal to produce an open environment, itsmethodology and training material, to develop embedded software for safety crit-ical systems that supports multi formalisms, simulation and animation, formalverification and automatic qualified code generation is achievable and industri-ally viable.

3 Adding Value to Models

Formal verification may have many faces. The ways formal verification can addvalue to models include:

– Certification of ECUs– Formal Debugging– Regression testing– Compositional / Grey box testing

each of which will be discussed in detail below.

3.1 Use Case 1: Certification of ECU Models

Formal verification gives complete coverage of a model with respect to func-tional, safety and real-time requirements. For example a functional requirementcould be: Intrusion alarm will be activated when window is crashed. A safetyrequirement: Steering wheel will never be locked when ignition is on. A real-timerequirement: Air bag fires at most 15 milliseconds after a crash. When verified tosatisfy the requirements, the model becomes a “golden device” and can be usedas a supplier specification. Later it can be used as a maturity gate prior to sign-off. This significantly reduces the potential for call-backs. Certification can alsobe used to show compliance to standards imposed by certification authorities forSIL 3,4 applications, such as

– Cenelec EN 50128 - B.30– DO 178B– IEC 61508

The ModelCertifier is a formal verification tool where requirements can beformalized with the help of a pattern library of typical temporal idioms. It in-cludes patterns like never P, always P, P not before Q, P within t time unitsafter Q etc. Where P and Q are conditions on data items or states of the ECU.


The formalized requirements are defined as proofs in a dictionary, where theyare maintained for the changes to the model or the requirements.

We have shown certification of Requirements on industrial ECU modelswithin 30 to 300 seconds and executed the formal verification of 36 requirementsfor an Airbag controller for a total certification in 20 minutes.

3.2 Use Case 2: Formal Debugging

Re−Check Re−Execute

Regression

Fig. 4. Regression Testing the Model

The ModelChecker is a tool which can be used to check the consistency of e.g.Statemate models automatically. It offers several analysis to debug specificationmodels. It is used for formal debugging and replaces hundreds of simulation runsby one verification run.

Types of Usage The ModelChecker provides the following types of checks on amodel. Non-Determinism: The fault when in the model two or more transitionsat the same level and with the same source can be fired simultaneously. Write-Write Races: The fault when a variable is written with two or more values at thesame time. Write-Read Races: The possible fault when a variable is written andread at the same time and it is not clear if the old or the new value should beread. ’Drive to State’: A reach-ability check. Range Violation: The fault whena variable can be assigned a value outside it’s valid range. Drive-To-Property:Checking that certain combinations of variable values can or cannot be reached.


The following are Drive-to-state verification time examples on complete ECUmodels averaged over all states:

– Autopilot: 30 minutes– Central locking: 2 minutes– EMF: 2,5 minutes– Car-Alarm: 3 minutes– Airbag: 1 minute

3.3 Use Case 3: Using formal verification for regression testing

The tight integration of the formal verification tools inside the CASE tool pro-vides another advantage. Model modifications (e.g. extensions and new features)are automatically propagated to the verification tool. All previous Check Resultspotentially effected will be invalidated automatically. The Batch mode of the ver-ification tool allows to re-verify all potentially invalidated requirements on thenew model to identify changes in verification results induced by the model mod-ification. We use a complete suite of ECU/function models regularly in housefor regression testing. See figure 4.

3.4 Use Case 4: Virtual Integration Test & IP Protection

Formal verification techniques can be used to do a virtual integration test in anearly design phase. On the one hand a virtual integration test highly reduces thenumber of errors not caught until sub-system integration test. And on the otherhand virtual integration test supports Intellectual Property (IP) protection ofsubsystems designed by third parties.

Technically, virtual integration is based on compositional reasoning. The gen-eral goal of compositional reasoning is to derive a global system property fromproperties of its components. Figure 5 illustrates the system-level verificationmethod based on compositional reasoning. Basic components are checked usingfor example ordinary model checking techniques. Composed structural units areverified by deriving the specification out of properties of its components.

A compositional verification step is based on

– a property of the composed system which should be checked,– properties of the components, and– structure and communication between the components.

Let us consider the example system shown in Figure 5. The goal is to verifythat the global system SYS satisfies the property Spec. To derive this propertyseveral steps have to be done:

1. At component level, prove appropriate properties of the components:– Spec1 1 and Spec1 2 for component C1, (IIa)– Spec2 1 for component C2, (IIb)– and Spec3 1, Spec3 2 and Spec3 3 for component C3. (IIc)


Env

Spec3_3

C3

Env

Spec3_2

C3

Env

Spec1_2

C1

Env

Spec1_1

C1

Env

Spec2_1

C2

C3

C2

C1

Env

Spec3_1

C3

b

Env

Spec

C1 C2 C3

b

C3

C2

C1

SYS

I

Env

Spec

C1 C2 C3

b

Env

Spec1_2

C1

Env

Spec1_1

C1Env

Spec2_1

C2

Env

Spec3_3

C3

Env

Spec3_2

C3

Env

Spec3_1

C3

b

+ structure

III

IIa

IIb

IIc

Fig. 5. Compositional verification


2. At the system level derive the global specification from the component prop-erties:– Spec is logically derivable from

Spec1 1, Spec1 2, Spec2 1, Spec3 1, Spec3 2 and Spec3 3 together withthe structure and the communication mechanism on system level.(III)

To do the compositional proof step (III) at system level no implementationdetails of the components are required. The step is based only on the formalrequirement specifications of the components. Hence this approach supports IPprotection in a manufacturer/suppliers design chain. The correctness of the com-ponents is guaranteed by the suppliers. A supplier can use, for example, modelchecking procedure to verify the local properties and he then needs only todemonstrate the certification of the local requirements of the component to themanufacturer. Hence there is no need for suppliers to provide full ECU specifi-cations to the manufacturer.

4 Enhancing Trust in Fault-Tree Analysis

Fault-tree analysis (FTA) is a widely adopted technique to systematically an-alyze causes for a given failure of a complex system. Traditionally, a fault treeis constructed top-down based on knowledge about the structure of the systemand the interaction of subsystems. With the increasing system complexity andthe accompanying introduction of model-based development techniques in theindustrial process, a substantial amount of this knowledge is laid down in thesystem models. But there are several issues with classical FTA:

Coherency:

– How do models used for safety analysis relate to the actual design?– How can safety engineers keep track with ongoing developments in the

design models?Plausibility:

– How can a system designer relate a cut-set to “her” model?– How can she understand, how the cut-set can arise?

Accuracy: How can– mission phases– numerical thresholds

. . . be assessed without gross over-approximation?Completeness:

– How can a safety designer assert that all minimal cut-sets have beenidentified?

The EU funded research project ESACS 14 (Enhanced Safety Assessment ofComplex Systems) addresses these topics. The technical and scientific objectivesof ESACS are to define a methodology to improve the safety analysis practice

14 http://www.cert.fr/esacs/


for complex systems development, to set up a shared environment based ontools supporting the methodology, and to validate the methodology through itsapplication to case studies. Figure 6 shows where the ESACS approach interfacewith the safety process as it is described in the ARP 4654 and 4761 documents.

Aircraft LevelRequirements

Allocation ofAircraft Functions

to Systems

Developmentof System

Architecture

Allocation ofRequirements to

Hardware &Software

SystemImplementation

Certification

System Development ProcessSafety Assessment Process

Aircraft

Functions

System

Functions

Failure Condition, Effects,Classification, Safety Objectives

Failure Condition, Effects,Classification, Safety

System

Architecture

Item Requirements

Aircraft LevelFHA

System LevelFHA Sections

PSSAsArchitectural

Requirements

CCAs

Functional Interactions

FailureConditions& Effects

Separation

Requirement

��

Implementation

Results

SeparationVerification

Item RequirementsSafety Objectives,Analyses Required

Physical System

Objectives

Fig. 6. The ESACS approach towards ARP 4754 and 4761

The ESACS project developed a common methodology for model based safetyanalysis. The Analysis can start with system model or conceptional design modelthat implements the nominal behavior of the system. The first step is to verifythat this model is correct with respect to the given safety requirements. In thenext step the nominal system behavior is enriched by failure modes. The failurescan be selected from a library of common failure patterns that has been devel-oped in conjunction with the industrial partners. A more detailed description ofthe ESACS methodology can be found in [23].

Each technology provider in ESACS implemented a vertical “line”, i.e. aninstantiation of the ESACS methodology. The OFFIS “implementation line”(STSA – Statemate Safety Analysis) is based on the modeling tool Statem-ate. The first step when doing an automatic safety analysis is to execute a set


of simple robustness checks (e.g. to find non-determinism and write/write orread/write races). After that it should be ensured that the nominal model ful-fills all safety requirements. When these preliminary steps have been taken careof, the actual fault-tree analysis can start with the definition of the top-levelevent (TLE). Simple properties can be defined directly in the STSA. More com-plex safety requirements can be imported from the ModelCertifier. The patternselection itself and the instantiation of pattern parameters is done within thisverification tool. The analysis results can be exported to the commercial Fault-Tree+ tool (Isograph) for further evaluation (e.g. quantitative analysis). Oftenit is not sufficient to know which failures contribute to a failure scenario but alsowhat is the exact system behavior leading to this situation. For this purposethe STSA tool can generate an an SCP (simulation control program) for eachcut-set. This SCP can be used together with the Statemate Simulator to drivethe system model directly to the top-level event.

The automatic FTA implemented in the STSA tool has been evaluated usingtwo case studies. The SPS (secondary power system) case study was provided byAlenia Aeronautica. There have been several instances of the same basic modelthat mainly differed in complexity. The second case-study, provided by AirbusGermany, was a design model of a controller for the High-Lift System of theAirbus A340 aircraft.

��

��

��

��

��

Fig. 7. The ESACS approach towards ARP 4754 and 4761

During the first evaluation cycle in ESACS the Slat part of that controllerwas evaluated. But because of the size of the system only subsystems could beanalyzed. During the second cycle a different approach was followed. Instead of


restricting the analysis to simple subsystems, timer and data abstraction tech-niques have been applied. A detailed description of the techniques and the resultscan be found in [24]. It has been found that through the use of abstraction, au-tomatic FTA is feasible even on very complex systems. Furthermore it has beenshown that the abstraction technique is safe, i.e. no cut-sets are dropped. But itis possible that some of the cut sets are too small, i.e. too pessimistic.

5 Closing the Gap Between Models and Systems

If for reasons of cost, space or time an implementation is not generated witha certified code generator, then there is a gap in the formal chain from themodel to the actual implemented system. Testing is a way to bridge that gap.But testing is time-consuming, costly and incomplete. Again formal verificationcan provide an aid. Formal Verification techniques can be used to automaticallygenerated a full set of test cases from a model. The aim of Automatic Test vectorGeneration (ATG) [25] is to automatically generate test vectors which cover theentire model. These can then be used for conformance testing e.g. Hardware Inthe Loop (HIL) and for regression testing. See figure 8.

Implementation

RequirementsUse Cases

GoldenDevice

ATG − AutomaticTestvectorGeneration:− input− expected output

Fig. 8. Advanced Verification Technology

Formal Verification and ATG are complementary. Where Formal Verificationprovides:

– Verification of functional, safety and timing requirements– Is purely model based and abstracts from target Hardware (HW) and Real-

Time Operating System (RTOS) and only uses abstract timing– Gives complete coverage and hence early detection of design errors and in-

tegration errors based on a virtual V


– Is automatic– Is used in the early phases of the V

ATG:

– Is a Bridge between (verified) models and real system for unit test, ECUtest, subsystem integration test and system integration test

– Testing can take into account real time, distribution and RTOS– Test vectors can be generated automatically– ATG can re-use the same requirements and models used for Formal Verifi-

cation

Testing is approximating formal refinement. Rather than the formal implies,it says that an implementation “complies to” a model. “Complies to” meansthat:

– The ECU must have the ’same’ interface behavior as golden device– ’same’: must map model interface objects to ECU interface objects– ’same’: cannot generate complete test set– Degree of approximation determined by user-selected test objectives

In the ATG approach, a user can specify coverage goals for the test generationlike basic states, transition and scenarios.

6 Conclusion

Numerous modeling issues can be identified and eliminated using formal debug-ging. A complete verification flow can be demonstrated on an safety critical ap-plication model. A model based SW engineering process supported by automatictools can lead to faster and cheaper development of more reliable automotiveapplications.

References

1. Damm, W., Schulte, C., Segelken, M., Wittke, H., Higgen, U., Eckrich, M.: For-male verifikation von ascet modellen im rahmen der entwicklung der aktivlenkung.Lecuture Notes in Informatics P-34 (2003) 340–345

2. Baufreton, P., Dupont, F., Lesergent, T., Segelken, M., Brinkmann, H., Strich-man, O., Winkelmann, K.: Safeair: Advanced design tools for aircraft systemsand airborne software. In: Proceedings of the 2001 International Conference onDependable Systems and Networks. (2001)

3. Clarke, E.M., Grumberg, O., Peled, D.A.: Model Checking. MIT Press,Cambridge,Massachusets, London, England (1999) ISBN 0-262-03270-8.

4. Owre, S., Rushby, J.M., Shankar, N.: PVS: A Prototype Verification System. InKapur, D., ed.: 11th International Conference on Automated Deduction. Volume607 of LNAI., Saratoga Springs, New York, USA, Springer-Verlag (1992) 748–752


5. Paulson, L.C.: Isabelle: a generic theorem prover. Volume 828 of Lecture Notes inComputer Science. Springer-Verlag (1994)

6. Hunt Jr., W.A., Somenzi, F., eds.: Computer Aided Verification, 15th InternationalConference, CAV 2003, Boulder, Colorado, USA, July 8 – 12, 2003, Proceedings.In Hunt Jr., W.A., Somenzi, F., eds.: Computer aided verification (CAV 2003).Lecture Notes in Computer Science, Springer Verlag (2003)

7. Maler, O., Pnueli, A., eds.: Hybrid Systems: Computation and Control (HSCC’03). In Maler, O., Pnueli, A., eds.: Hybrid Systems: Computation and Control(HSCC ’03). Lecture Notes in Computer Science, Springer Verlag (2003)

8. Bienmuller, T., Damm, W., Wittke, H.: The STATEMATE verification environ-ment – making it real. In Emerson, E.A., Sistla, A.P., eds.: 12th InternationalConference on Computer Aided Verification, CAV. Number 1855 in Lecture Notesin Computer Science, Springer-Verlag (2000) 561–567

9. Bryant, R.E.: Graph-based algorithms for Boolean function manipulation. IEEETransactions on Computers C-35 (1986) 677–691

10. Coudert, O., Berthet, C., Madre, J.: Verification of synchronous sequential ma-chines based on symbolic execution. In: Automatic Verification Methods for FiniteState Systems. Volume 407 of LNCS., Springer Verlag (1989) 365–373

11. Stalmarck, G., Sflund, M.: Modeling and verifying systems and software in propo-sitional logic. In Daniels, B.K., ed.: Safety of Computer Control Systems (SAFE-COMP’90), Pergamon Press (1990) 31–36

12. Moskewicz, M.W., Madigan, C.F., Zhao, Y., Zhang, L., Malik, S.: Chaff: Engi-neering an Efficient SAT Solver. In: Proceedings of the 38th Design AutomationConference (DAC’01). (2001)

13. Filliatre, J.C., Owre, S., Rueß, H., Shankar, N.: ICS: Integrated canonizer andsolver. In Berry, G., Comon, H., Finkel, A., eds.: Proceedings of the 13th Interna-tional Conference on Computer Aided Verification (Paris, France). Volume 2102of Lecture Notes in Computer Science., Springer Verlag (2001) 246–249

14. Stump, A., Barrett, C., Dill, D.: CVC: a cooperating validity checker. In Godske-sen, J.C., ed.: Proceedings of the International Conference on Computer-AidedVerification. Lecture Notes in Computer Science (2002)

15. Shankar, N.: Combining theorem proving and model checking through sym-bolic analysis. In: 11th International Conference on Concurrency Theory (CON-CUR). Volume 1877 of Lecture Notes in Computer Science., University Park, USA,Springer-Verlag (2000) 1–16

16. Basin, D., Friedrich, S.: Combining WS1S and HOL. In: Frontiers of CombiningSystems 2 (FROCOS). Research Studies Press/Wiley (2002) 39–56

17. Bemporad, A., Morari, M.: Verification of hybrid systems via mathematical pro-gramming. In Vaandrager, F.W., van Schuppen, J.H., eds.: Hybrid Systems: Com-putation and Control (HSCC’99). Volume 1569 of Lecture Notes in ComputerScience., Springer Verlag (1999) 31–45

18. Clarke, E., Grumberg, O., Jha, S., Lu, Y., Veith, H.: Counterexample-guidedabstraction refinement. In Emerson, E., Sistla, A., eds.: Computer Aided Verifica-tion. Volume 1855 of Lecture Notes in Computer Science., Springer Verlag (2000)154–169

19. Glusman, M., Kamhi, G., Mador-Haim, S., Fraer, R., Vardi, M.: Multiple-counterexample guided iterative abstraction refinement: An industrial evaluation.In Garavel, H., Hatcliff, J., eds.: Tools and Algorithms for the Construction andAnalysis of Systems. Volume 2619 of Lecture Notes in Computer Science., SpringerVerlag (2003) 176–191


20. S. Graf, H. Saidi: Construction of abstract state graphs with PVS. In Grum-berg, O., ed.: Proc. 9th INternational Conference on Computer Aided Verification(CAV’97). Volume 1254., Springer Verlag (1997) 72–83

21. Ball, T., Majumdar, R., Millstein, T., Rajamani, S.K.: Automatic predicate ab-straction of C programs. SIGPLAN Notices 36 (2001) 203–213 Proceedings ofPLDI 2001.

22. Becker, B., Behle, M., Eisenbrand, F., Franzle, M., Herbstritt, M., Herde, C.,Hoffmann, J., Kroning, D., Nebel, B., Polian, I., Wimmer, R.: Bounded modelchecking and inductive verification of hybrid discrete-continuous systems. In:ITG/GI/GMM-Workshop “Methoden und Beschreibungssprachen zur Model-lierung und Verifikation von Schaltungen und Systemen”. (2004)

23. Bozzano, M., et al.: Esacs: An integrated methodology for design and safety anal-ysis of complex systems. ESREL (2003)

24. Bretschneider, M., Holberg, H.J., Bode, E., Bruckner, I., Peikenkamp, T., Spenke,H.: Model-based safety analysis of a flap control system. INCOSE (2004)

25. Bohn, J., Damm, W., Klose, J., Moik, A., Wittke, H.: Modeling and validating trainsystem applications using statemate and live sequence charts. In Ertas, A., Ehrig,H., Kramer, B.J., eds.: Proceedings of the Conference on Integrated Design andProcess Technology (IDPT2002), Society for Design and Process Science (2002)

adding value to automotive models - Semantic Scholar · PDF file ·...

Documents

Transcript of adding value to automotive models - Semantic Scholar · PDF file ·...