Using language workbenches and domain-specific languages for safety-critical software development
0 likes57 views
The document discusses the use of language workbenches and domain-specific languages in developing safety-critical software for healthcare applications, emphasizing the importance of efficiency and reliability in algorithm development. It outlines a solution approach where healthcare professionals code algorithms directly, allowing for faster development and addressing safety standards to mitigate systematic errors. Ultimately, the approach demonstrated improved efficiency, reduced error rates, and enhanced collaboration, confirming the success of the method in a regulated environment.
Using language workbenches and domain-specific languages for safety-critical software development
- 1. Markus Völter voelter@acm.org www.voelter.de @markusvoelter Using Language Workbenches and Domain-Specific Languages for Safety-Critical Software Development M. Voelter, B. Kolb, K. Birken, F. Tomassetti, P. Alff, L. Wiart, A. Wortmann, A. Nordmann
- 2. Markus Völter voelter@acm.org www.voelter.de @markusvoelter Using Language Workbenches and Domain-Specific Languages for Safety-Critical Software Development M. Voelter, B. Kolb, K. Birken, F. Tomassetti, P. Alff, L. Wiart, A. Wortmann, A. Nordmann
- 4. Context Mobile Apps that help patients w/ treatments Monitor side-effects and recommend actions Manage dosage of medications
- 5. Context Mobile Apps that help patients w/ treatments Monitor side-effects and recommend actions Manage dosage of medications “Algorithms“ for recommendations and dosage at the core of these apps. Safety-critical, since they could hurt patients. Customer develops many different apps/algos like this, efficiency of algo development is key.
- 8. Solution Approach Health care professionals directly „code“ algos, using a suitable language. Avoids indirections through requirements docs. Speed up dev significantly. }Pretty typical DSL-based dev- approach. What good is all the abstraction if we cannot trust the translation to the implementation?
- 10. Some Language Impressions II
- 11. Some Language Impressions IV
- 13. Languages Used
- 14. Languages Used
- 15. What good is all the abstraction if we cannot trust the translation to the implementation? System Architecture What good is all the abstraction if we cannot trust the translation to the implementation?
- 16. What good is all the abstraction if we cannot trust the translation to the implementation? System Architecture & Safety Standards Tools may introduce additional systematic errors if faulty. Safety standards require reliable mitigation of such errors. DO-178C EN50129 IEC62304 ISO26262
- 17. What good is all the abstraction if we cannot trust the translation to the implementation? System Architecture & Safety Standards Tools may introduce additional systematic errors if faulty. Safety standards require reliable mitigation of such errors. DO-178C EN50129 IEC62304 ISO26262 Good Abstractions Good Notations Simulation Testing => Checking => Review => Experimentation => Trust
- 18. 3 Safety
- 19. What good is all the abstraction if we cannot trust the translation to the implementation? Unqualified Tools!
- 20. End-to-end testing required. How to do this without exploding effort? Unqualified Tools! Redundancy catch errors in redundant path while reducing manual effort. Automated + specific risk mitigations
- 21. + Risk Analysis + Mitigations Modeling Architecture Model the Algo/System with the DSL and also model the tests/verification. Then translate both and execute on the level of the implementation.
- 22. Risk Analysis
- 23. Mitigations – Safe Modeling Architecture
- 24. Mitigations – Safe Modeling Architecture use redundant execution on two execution engines use different developers for the two trafos review a subset of the generated code clearly define and QA the DSL to use fuzzing on the tests ensure high coverage for the tests run the tests on the final device perform static analysis on the generated code perform penetration testing on the final system and use architectural safety mechanisms. only these specific to DSL use
- 25. Mitigations – Safe Modeling Architecture use redundant execution on two execution engines Lots of overhead? Not really. C++ interpreter on device In-IDE Java Interpreter Validation: the in-IDE interpreter is used for interactive testing, exploration, understanding, simulation. HCP‘s single-most appreciated use of the models! Verification: addresses unrelated but compensating, as well as related errors in the transformations. Does not rely on trafo engine, so finds error in it. It‘s also simple (!fast), so acts as a specification.
- 26. Test Stats and other Numbers 100% line coverage regarding language structure, Java interpreter and C++ interpreter Validation Effort Reduction from 50 PD to 15 PD Test Setup Effort reduced by a factor of 20 Shortened Turnaround for req -> impl -> write tests -> execute tests b/c of much better tool integration „Tremendous Speedup“ for changes to algo after it has been validated – automatic reexecution of everything. Two reference Algos, 305 test cases for Bluejay, 297 for Greenjay, plus lower-level tests for decision tables and trees
- 28. For everything that can be seen as taking a list of arguments, those can be synthesized. Test Generation
- 29. For a set of tests that all succeed, if after a change to the program they still do, this is a problem. Mutation / Fuzzing
- 30. 4 Did it work?
- 31. Of course. Everything got cheaper, faster and better :-) FDA pre-sub. Iteration times Stakeholder collaboration Quality But it wasn’t all smooth sailing … Culture Change Investment
- 32. WRAP UP
- 34. Overall Efficiency and Quality Developing a good DSL is Work The Safety Mechanisms Work - Formality and Fancy Notations A Model is not enough - goals were achieved as expected. both conceptually and technically. overall error rate much lower than in manual coding as supported by MPS are useful for validation analysis, simulation, testing, debugging is crucial. Yes, we‘d do it again.