1 / 34

SCADE

A study in airworthiness. SCADE. SCADE Introduction ARP 4754 Development process SCADE Suite / DO-178B LUSTRE Programming language Example & Demo Conclusions Questions. Agenda. S afety C ritical A pplication D evelopment E nvironment by Esterel Technologies.

vin
Download Presentation

SCADE

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. A study in airworthiness SCADE

  2. SCADE Introduction ARP 4754 Development process SCADE Suite / DO-178B LUSTRE Programminglanguage Example & Demo Conclusions Questions Agenda

  3. Safety Critical Application Development Environment by Esterel Technologies. Commercialproductratherthanspecificationor standard Basedon formal lang. LUSTRE Industrialusesinclude: Airbus 380/340, nuclear power plants. Scadesrole : Control software (prim. Avionics) Generates DO-178B qualifiedsourcecode. Introduction (1)

  4. Features • Graphical and textual editor • Simulator • Design verifier for LUSTRE • Since v. 5.1, also: • Gateways to Simulink and Rhapsody (IntegratingSysML and SCADE) • Requirements Management Gateway (tracability) Introduction (2)

  5. Applicant vs Authority Assuresafetyduringdevelopmentofcomplex systems Provide common international basis for compliance with air-requirements During DO-178B revision it was discovered that system level information was required as input (tracability) Facilitate understanding, not dictate structure ARP 4754

  6. “Development assurance levels” instead of test suites for errors that are not deterministic (Minimum of errors) Systematic actions to establish confidence that system satisfied certification requirements. Activities = supporting processes (figure) System Development Assurance (1)

  7. Systems and items assigned DAL based on failure condition classification Rigor and dicipline involved in performing supporting processes is based on this level! This level determines level of DO-178B System Development Assurance (2)

  8. Two key elements: • Visibility of processes • Illuminate how the safety process interacts with other supporting processes System Development Assurance (3)

  9. Concluding: • ARP 4754 arises from the differences between software and system development assurances. System Development Assurance (4)

  10. Top level: Functions + safety reqs => systems architechture => Additional requirements • Safety reqs: Functional Hazard Assesment • Failureconditions, Consequences. • Derived requirements • Each phase derives from previous (not uniquely related, part of design proces) • Assignment of DAL’s: • Use architechture to reduce degree of errors (permit lower assurance levels) Requirement determination

  11. Interacts with other supporting processes Shows compliance with airworthiness requirements SafetyAssesment

  12. Are requirements correct and complete so the product will meet airworthiness reqs? • Ensure correctness and completeness • At eachlevelofrequirementhierarchy • Completeness, correctness, validationofassumptions • Rigorofvalidation: Determined by assurance level • All req’stracable, Analysis, Modeling (SCADE), Testing • Reccommendation: TRACEABILITY AND MODELING required for A&B dev assurance (…and more) ValidationofReqs

  13. Ensure that implementation meets verified requirements. With SCADE it’s possible to verify this while also modeling requirements. Level of verification = dev assurance level Review problems => Scade output on safety parameters. (could fail) ImplementationVerification

  14. Identification of Aircraft-Level Functions, Functional Requirements, and Functional Interfaces Determination of Functional Failure Consequences and Implications Allocation of Functions to Systems and People Design of System Architecture and Allocation of Requirements to Items Allocation of Item Requirements to Hardware and Software Hardware and Software Design/Build Hardware/Software Integration System Integration Genericprocessactivities

  15. Requirements allocated to hardware / software DAL for each requirement and a description of associated failure condition(s), if applicable. Allocated failure rates and exposure interval(s) for hardware failures of significance. System process to software lifecycle (1)

  16. Hardware/software interface description (system design). Design constraints, including functional isolation, separation, and partitioning requirements. System validation activities to be performed at the software or hardware development level, if any. System verification activities to be performed at the software or hardware development level. System process to software lifecycle (2)

  17. Description of the implementation architecture, including achieved independence and fault containment capabilities Evidence of the proper level(s) of development assurance, including any assurance achieved through tools Evidence of system level requirements validation activities performed at the software or hardware development level. software lifecycle to System process (1)

  18. Evidence of system/item verification activities Hardware failure rates, fault detectability coverage, and fault latency intervals Problem or change reports that may impact system or item requirements, to be evaluated against the system or item requirements and the PSSA software lifecycle to System process (2)

  19. A combination of controlengineering and software engineering. • Modular design -> If a node is verified, it is verified in all possiblecontexts. • Graphicalrepresentation • In SCADE Editor nodes arerepresented as graphicalentities. • Textual notation -> semantic reference used by the tool SCADE TextualLanguage

  20. Fullymodular: • Clear distinctionbetween interface and body • Noside-effects from node to node • Behaviourdoes not dependoncontext • Canbeusedseveralplaces in the same model orseveral models SCADE Node (1)

  21. SCADE Node (2)

  22. Continouscontrol: Sampling of sensors, signalprocessing, computingcontrollaws. • For thisblock diagrams areused. • Discretecontrol: Changingbehaviouraccording to external events. • Safe State Machines areused Discretecontrol vs. Continouscontrol

  23. The SCADE language handles concurrency and dependencyautomatically: • If nodes are independent of eachother the relative computationorderdoes not matter. • If nodes have functionaldependenciesthis is automaticallytakenintoaccount and the generatedcodeexecutes the functions in the correctorder. Concurrency and Dependency

  24. Concurrency and Dependency

  25. Continous loop • Sensors areread • Computationperformed • Output generated • Rinserepeat Computation model

  26. A complete SCADE IDE supporting the following: • Requirements management (Requirements Management Gateway) • Model design (SCADE Editor and SSM Editor) • Model simulation (SCADE Simulator) • Formal verification (Design Verifier) • Code generation (SCADE Code Generators) SCADE suite

  27. Dataflow synchronous  language for reactive systems Dataflow means close to usual tools (block diagrams etc) = conformance Formalism allows writing programs / expressing properties => easy verification methodology. Reacts instantanously to external event => determinism LUSTRE INTROduction

  28. Monitoring systems, logical systems -> described by parallel automata (STATECHARTS, Petri Nets : describe states and transitions) Programs written without referring to state transitions. Describe state variables and invariants PROVEN:  Any finite state machine can be described by a boolean LUSTRE program Mix systems LUSTRE (Language)

  29. absence of cyclic definitions Produces sequential code Borrowsconcepts from ESTEREL LUSTRE (Compiler)

  30. Safetyof a criticalappdoes not dependonthe total correctnessofitscontrol program but ratheron a smalll set ofpropertiesthatthe program shouldfulfill (safety props) Proofhandledwithinframework Safety prop canbeverified by checkingpropertiesofreachablestates LUSTRE (Verification)

  31. Wewant to introduce a change in the system • i.e. new safetyproperty: Norolls faster than 15 degrees per second (assumptionturns to data) • Entry point ofchangecanoccur at any point in thedevcycle. • Assessimpactonotherfunctions and onhigherlevelrequirements Example & DEMO

  32. ARP 4751 introduced to addaspect of system engineering to existingdevprocess • International understanding of process • New Requirement Management Gatewayaddstracability • New RhapsodygatewayintegratesSysML and SCADE => More tracibility to a widerunderstandingof domain) Conclusion (1)

  33. Experienceswith SCADE: • Fast development • Easyverification • Easycode generation • Good Test/ErrorTraceability Conclusion (2)

  34. Questions?

More Related