1 / 14

If you can’t verify what you get, …

If you can’t verify what you get, …. Reinhard Wilhelm Informatik Saarland University and AbsInt. Messages. An old song: “If you can’t be with the one you love, love the one you’re with!”

saddam
Download Presentation

If you can’t verify what you get, …

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. If you can’t verify what you get, … Reinhard Wilhelm Informatik Saarland University and AbsInt

  2. Messages • An old song: “If you can’t be with the one you love, love the one you’re with!” • Some Boeing vice-president, at a National Aviation Day: “The non-existence of a verification method required by a design method will not prevent us from using this design method.” • My message: “If you can’t verify what your client has developed, help him to construct what you can verify!” in other words: • Design and implementation methods on one side and verification methods on the other side should be good matches! • An example from another domain: Giesecke & Devrient

  3. Taking Constructive Influence • Not every (correct) system is amenable to (efficient) verification. • Complexity can be vastly reduced and precision (in the case of static analysis) vastly improved by appropriate design. • This claim is proved by experience with model-based design in the embedded systems domain. • For the proof of functional correctness, coding guidelines, e.g. MISRA C, are supposed to help.

  4. Timing Analysis - Two Enemies instead of One - • Unpredictable architectural platform • Non-analyzable applications The Timing-Analysis Problem Given: • a softwaretoproduce a reaction, • a hardwareplatform, on whichtoexecutethesoftware. • a requiredreaction time, Derive: a guaranteefortimeliness.

  5. What does Execution Time Depend on? Caused by caches, pipelines, speculation etc.  Explosion of state space Input • the input, • the initial and intermediate execution states of the platform, • interferences from the environment – this depends on whether the system design admits it (preemptive scheduling, interrupts). Software Architecture initial state “external” interference as seen from analyzed task, see Jan’s lecture

  6. Notions in Timing Analysis Hard or impossible to determine Determine upper bounds instead

  7. Tool Architecture Abstract Interpretations Abstract Interpretation Integer Linear Programming

  8. The Architectural Abstraction inside the Timing Analyzer Timing analyzer Architectural abstractions Value Analysis, Control-Flow Analysis, Loop-Bound Analysis Cache Abstraction Pipeline Abstraction

  9. Experience Breakthrough in 2001. C. Ferdinand, R. Heckmann, M. Langenbach, F. Martin, M. Schmidt, H. Theiling, S. Thesing, R. Wilhelm: ReliableandPrecise WCET Determination for a Real-Life Processor. EMSOFT 2001: 469-485 Reasons: • The application of the right combination of formal methods, • The will to solve the problem.

  10. Abstraction and Decomposition Components with domains of states C1, C2, … , Ck Analysis has to track domain C1 C2…  Ck Start with the powerset domain 2 C1 C2…  Ck Find an abstractdomain C1# transforminto C1#  2 C2…  Ck Find abstractions C11# and C12# factor out C11# andtransform rest into 2 C12# …  Ck This has worked for caches and cache-like devices. This has worked for the arithmetic of the pipeline. program with annotations program C11# 2 C12# …  Ck microarchitectural analysis value analysis

  11. Usability and Acceptance • Required user (SW designer) interaction with tool: • annotation with architecture and application information • both not easily available! • Typically called to a first-time user too late – system developed with non-analyzable features • Accepted and integrated into tool chain at Airbus and some suppliers

  12. Problems Two different problems - two different originators • architectural unpredictability:computer architects – hard to convince! • Non-analyzability of software:SW designers – get direct feedback, slowly learningHW and SW architecture need to be designed for analyzability • Trends in the automotive and aeronautics industries: AUTOSAR and IMA • Transition from federated to integrated architectures • IMA: concepts ok, implementations unusable • AUTOSAR: bad start, slowly developing, implementation?

  13. Timing Predictability Reconcile performance with predictability in architectural design Current architectures are optimized for average-case performance Question: How can one design an architecture with efficiently determinable good worst-case performance? Strong results on caches, PhD dissertation of Jan Reineke PPES Workshop at DATE 2011 in Grenoble Paper by AbsInt on Dos and DON’Ts

  14. Different Specification Formalisms • German car industry specifies cars in Simulink/Stateflow • Simulink for control loops • Stateflow for, among others, operating modes • Control loop influences states • Transitions in the finite state machine influence control parameters • Designers don’t properly switch between simulink and stateflow!

More Related