Structure of Presentation Introduction Challenges in the - PDF document

Structure of Presentation • Introduction Challenges in the Verification of • Challenge 1: Variety of modeling languages Electronic Control Units • Challenge 2: Learning curve for Requirement Capture • Challenge 3: Integration with Verification Engines • Challenge 4: Verification Technology for real-life models Werner Damm • Challenge 5: Closing the bridge between models and OFFIS systems R&D Division of Embedded Systems • Conclusion To capitalize on models The challenge “... switching to reverse Requirements System caused the car to boost Cost, Use Cases Time, backwards like a rocket Risk ...” Analysis System model “ ... even pressing the Test brake could not stop Iterative Modeling Prototype * Application the car...” Complexity Managing the unexpected under cost - Implementation and timing - constraints Classical Verification Technology Our mission • Sample scenario • Designer / test – User plays with remote engineer follows control: on-off-on-off-... “typical” cases Helping to increase product quality by introducing – Door unlocking inhibited advanced validation techniques • But problems stem after 10 rounds to prevent into the development process from unexpected overheating of electric cases motor • Automotive • Avionics – Prevents door from – BMW, DaimlerChrysler, – Aerospatial, Alenia, being unlocked in crash GM, Opel, PSA, Siemens Britisch Aerospace, Electric Open AT DASA, Israeli Aircraft Controller Motor Industry, Snecma • Train Systems Enabled Disabled – Adtranz, Deuta, Siemens Close Car Driver VT under negotiation

Advanced Verification Technology I Advanced Verification Technology II • Extremely large state Requirements Requirements spaces can be analyzed ATG - Use Cases completely in minutes Use Cases Automatic – For all combination of Testvector inputs Generation: - input System model – For all sequences of Golden - expected output combination of inputs Device Model Checker • 100% coverage with respect to requirements Model Checker • Creates “golden device” / Implementation Implementation formally proves reference model consistency of Requirements and System model About FV • The maturity level of the system • Process maturity level in development process is highly avionics extremely high Challenge 1 dependent on the application • SW quality is a process issue domain – FV covers only very tiny • focus of this work: fraction of SW development – automotive process Variety of modeling languages – avionics – disturbances caused by – train systems introducing FV may easily • all hard real time outweigh potential benefits • all have safety critical subsystems FV must be subordinate to general process considerations FV must be interfaced with industry standard design tools Design Views supported by About FM STATEMATE • Case Tools used today in • Wrong: automotive - avionics - force developers to learn train systems formal methods – Mathlab/Simulink + Stateflow – MatrixX + Better State • Right: – STATEMATE make industry standard – SCADE design tools formal – ASCET – Rhapsody in MicroC – Titus – ObjectGeode (SDL) – Rhapsody in C++ (UML) – Telelogic Tau Suite

SCADE - Safety Critical Application Development STATEMATE Environment Synchronous data flow language for specification and design of Reactive Real Time systems (Graphical Frontend for LUSTRE) • Industry standard case tool • Animation marketed by I-Logix Inc • Simulation Features: • Activity Charts Editors ( dataflow, state-machine,...) • RP code generation · Simulator – System Architecture · • documentation · Code Generator for C and ADA – Information Flow · Document Generator – Environment • Widely used in automotive and • State Charts avionics, increasing usage in – visual real-time programming train-systems language – hierarchy – orthogonal states – algorithms Design Views Supported in Design Views Supported by Object Rhapsody Geode Problems Problems (cont.) • Even within one front-end tool no or underspecified • Real life applications typically require multiple tools relation between multiple views – e.g. hybrid controllers expressed in Statemate and MatrixX – e.g. relation between scenarios and behavioural model – e.g. plant model in Matlab/Simulink and controller model in Statemate • Even within one modeling style different semantics – e.g. specification model in Matlab/Simulink, code generation using between different implementations Scade – e.g. the 100+x semantics of statecharts – e.g. specification model in Statemate and design in UML tool • Even within one view in one tool underspecification • Today only limited support even for co-simulation – e.g. handling of deferred events in UML – e.g. detecting when plant state should trigger discrete transition • Even within one view in one tool differences between • Need to give semantic foundation to such combinations simulation semantics and code generation semantics – e.g. hybrid automata – e.g. timeouts

Lines of Attack Statemate, Rhapsody in C++ Sequence Charts Scade, Stateflow, ASCET Timing Diagrams VHDL Model-compilation Requirement-compilation • Deep background in formal semantics is a must • Deep understanding of actual tool usage is a must – focus on widely used modeling features SMI/SSL TBA – let designers point to weak aspects of modeling tool – let designers report on ambiguities • Deep cooperation with tool developers is a must • Develop reference semantics Test Compile / Synthesis Verification instrument • validate with tool provider generation • validate with designers Verification Test-bench Synth. C SMI evidence VHDL Anticipated application scenario • Distributed implementation on network of ECUs • Task: one active object grouped with a collection of An active object model passive objects • intertask communication typically asynchronous • operation calls used for intertask communication to Giving meaning to UML bypass event queue, expected to be infrequent • calls to primitive operations are executed in same thread joint work with Bernhard Josko and Amir Pnueli Model characteristics Design issues • Single thread of control in each • The driver role • When do we allow objects to active object – object stable switch from driver to callee • run-to-completion semantics – complete serialization of • rests in piece role? incoming operation calls and – dispatch single event from • waiting for work events • How do we decide whether to event queue – picks event from event queue dispatch a new event or to take – required to enhance – evaluate state chart until stable – thus triggering a new run-to- understandability and a call? configuration is reached completion step verifiability • design decision: level of • Ready_Set of configuration: – invoking operation calls – hence support only protected interference – driving its run-to-completion – set of events and operation call operation calls to triggered – can higher priority calls occurring as guards in • The callee role operations preempt ongoing run to potentially enabled transitions – object executes operation call • each active objects comes completion steps? • What happens if selected on behalf of some other object equipped with operation call is not in ready – tradeoff between model – helping some other guy to – event queue complexity and enhanced set? complete its run-to-completion responsiveness – queue of pending operation step • What happens if dispatched calls – will explore both variants event is not in ready set?