Agile Methods for Open Source Safety-Critical Software

1. Agile Methods for Open Source Safety-Critical Software by: Kevin Gary, AndinetEnquobahrie, Luis Ibanez, Patrick Cheng, ZivYaniv, Kevin Cleary, ShylajaKokoori,BenjaminMuffih, and John Heidenreich Presented by: Tim Fleck Most of the material presented is directly attributed to the authors of the topic paper

2. Safety-Critical System • Also called Life-Critical systems • Failure or a bug can result in loss of life or equipment damage. • Often can require external agency certification for use – FAA, FDA, NRC...

3. Safety Critical Systems • Anti-lock Breaks • Nuclear Control Systems • 9-1-1 Dispatch • Fire Alarms • Insulin Pumps • Roller Coaster Controllers • Avionics • Image-Guided Surgical ToolKit(IGSTK)

4. Common Themes inSafety Critical Systems • Heavily engineered and managed • Methods with high overhead that would not be cost effective often used in developing these systems • Agile methods and open source development uncommon

5. Introduction • Starting Quote “It seems to be a universally accepted maxim that agile development methods are not suitable for safety-critical domains.” • Main weaknesses • Documented Design • Requirements Management • Traceability

6. Agile and Open Source • Open Source often employs Agile methods • Concurrent development • Fast sprints • Gated production • OSSD also uses highly skilled distributed volunteers with no singularly available customer

7. The Author’s Argument “This recent evidence suggests that now is a good time to step back and reconsider the broader implications of agile methods for safety-critical software.”

8. Image-Guided Surgical Toolkit (IGSTK) • Open Source Project • Provides features for Image Guided surgery • Image import • Image display • Device tracking • OS portability • Many others • “rare intersection of agile and open source processes in a safety-critical domain.”

9. Why Discuss the IGSTK? • The authors are using the IGSTK as the backdrop for their discussion • It is an open source project that has employed agile methods since 2004 • The IGSTK has be adopted by teaching hospitals and research labs

10. Agile • Scrum • XP • Sprint • Iteration • Methodology • Discussion?

11. Background • According to the authors “Software safety deals with minimizing threats or risks to the system and mitigating loss in the event of failures or adverse events.” • Leveson defines risk as “a function of the probability of a hazardous state occurring in a system, the probability of the hazardous state leading to a mishap, and the perceived severity of the worst potential mishap that could result from the hazard”.

12. Engineering Safety Critical Systems • High levels of assurance • Testing • Other methods of checking(validation, inspection, ???) • Prevent malicious actions • Concern for inadvertent actions

13. Thoughts Against Agile • From Barry Boehm’s paper they reference • No stable requirements • Insufficient planning

14. Author’s Response – insufficient planning means more risk • Agile methods plan while focusing on empirical process control as a constant oversight and management mechanism • Scrum plans via its backlog, which can include risk reduction activities (HA, FTA FMEA) • Pervasive process control through sprints, standups and visibility

15. Author’s Response – Stable Requirements • Scrum (Agile) recognizes that change happens and is designed to deal with it • Changes can be adapted into sprints and will not need to be worked in ad hoc.

16. Author’s Response – Don’t Overlook the Team • Software is the output of a human-oriented process • The expertise of the team, the communication patterns it utilizes, and the human capacity to reason with incomplete knowledge are important factors in determining that output (the software).

17. Other Agile Experts Speak Out • eWorkshop – when performance requirements and plans about level of testing for the project are made at an early stage in development, agile methods are ideal for safety critical systems because in an agile approach the customer is available throughout the development process to obtain and clarify requirements.

18. Gelowitzet al. - They say XP performs all the phases better, except it does not create elaborate design document during the design phase. However, they also say that not creating elaborate design documents provides flexibility with respect to accommodating changes.

19. IGSTK Overview • Many challenges • Integrating physical devices such as robotic arms and trackers • Usable by specialized used such as surgeons • Fail-safe • Correctness and soft real-time • Ensured safety • IGSTK is an open source framework for creating surgical applications

20. IGSK Process challenges • Framework requirements can’t be fully understood until applications constructed • Use cases selectively useful for similar reasons

21. IGSK Process challenges • Distributed team of academic and commercial collaborators. • Challenges setting expectations and deliverables.

22. IGSK Process challenges • High quality standards • End of sprint code reviews • OS patterns of code releases

23. Architecture Challenges • Creating a safe platform - State machine design • Maintaining good communication practices • Strong central design patter amid strong open source evolutionary principles. • Minimizing configurability

24. 6 Key areas for safety 1. Hazard Analysis: identification and analysis of hazards in terms of their severity of effects and likelihood of occurrence. 2. Safety requirements specification/analysis: specify requirements in formal notation, allowing formal analysis to investigate whether certain properties are perceived. 3. Designing for safety: focus on consequences to avoid in the general system context.

25. 6 Key areas for safety 4. Testing: tests should demonstrate that the software responds appropriately to some anticipated environment. 5. Certification and standards: this involves assessing it against certain criteria. 6. Resources: Utilizing resources and books for good software safety engineering

26. Best Practices - 1 Recognize that people are the most important mechanism available for ensuring high quality software [9]. The IGSTK team is comprised of developers with a high degree of training and experience with the application domain, supporting software, and tools. Their collective judgment is weighted over any high-level process mandate.

27. Best Practices - 2 Promote constant communication. This is difficult in open source projects with distributed and part-time teams. IGSTK members constantly communicate through weekly teleconferences, biyearly meetings, mailing lists, and an active Wiki.

28. Best Practices - 3 Produce iterative releases. IGSTK’s external releases coincide with IGSTK yearly user group meetings. Internally, releases are broken down into approximately two month “sprints”. At the end of a sprint, the team can stop, assess and review progress, and determine what code is considered stable enough to move to the main code repository.

29. Best Practices - 4 Manage source code carefully. Require 100% mainline code coverage. Use sandboxes for evolving code with different check-in policies to allow developers to share experimental code without sacrificing quality policies in the mainline.

30. Best Practices - 5 Augment the validation process with reverse engineering tools that support complex white-box testing. This best practice is a nod to the specialty of the domain.

31. Best Practices - 6 Emphasize continuous builds and testing. IGSTK uses the open source CDashtool to produce a nightly dashboard of builds and unit tests across all platforms. Developers are required to ensure that code coverage stays as close as possible to 100%, that their source code builds on all supported platforms, and that all unit tests pass.

32. Best Practices - 7 • Support the process with open tools. IGSTK uses CDash, a test dashboard, CMake, a cross-platform build solution, and Doxygen, a documentation system.

33. Best Practices - 8 Emphasize requirements management in lockstep with code management. As requirements evolve and code matures, it is necessary to adopt flexible processes for managing requirements and source code. The organization and tracking of requirements is a complex process for a project such as IGSTK, and thus is detailed in the next section.

34. Best Practices - 9 Focus on meeting exactly the current set of requirements. This is one of the most important benefits of an agile approach. The team focuses on only the current backlog, not burdening itself on designs not realized in the current code.

35. Best Practices - 10 Allow the process to evolve. Through constant communication, IGSTK members recognize when the complexities they face can be addressed within the current process, when “tweaks” are required, or when new practices should be adopted.

36. Best Practices • None of these new to Open Source or Agile practitioners • Insufficient in themselves for safety-critical systems • IGSK expands on 4 areas • lightweight requirements management (#8) • safety-by-design (#9) • continuous integration and testing (#6) • architecture validation (#5)

37. Requirements management • Developers introduce new requirements into backlog • Collaborative process for reviewing, implementing, validating and archiving • Initialized and defined • Rejected/Aborted or accepted by team decision • Verified when implemented and functionally confirmed

38. Safety by Design • State machine with strong encapsulation • IGSTK documents the critical elements of component design, including its state machine catalog, on the Wiki • IGSTK conducts manual inspections and automated validation of these design implementations.

39. Continuous Integration and Testing • IGSTK relies heavily on the agile practice of continuous and extensive unit testing with automated tool support. • Ctest tool which posts to Cdash • Tests from systems around the globe • OS provides a global community of early adopters

40. Architecture Validation • validation tool suite is a simulator that accepts descriptions of state machines in SCXML reverse engineered from the source code • Tool created by project • Design done via Wiki and modeling constructed within the source code • The validation suite of tools checks the fidelity of the model’s representation and execution semantics

41. Safety • Difficult to assess due to it being a framework without specific application code • Evaluated using a modified Architecture Tradeoff Analysis Method • The modified process examined IGSTK documentation from all sources (Wiki, code, mailing lists, book, papers, etc.) to extract the key quality attributes and characterizations,

42. IGSTK Discussions Documentation should not be an afterthought: documentation is created as the code is being developed through a) a Wiki that is constantly updated, 2) automated online documentation created from the source via Doxygen, and 3) a freely available book which is created from the source tree via the same build process as the source code.

43. IGSTK Discussions Software quality assurance practices and standards should be established: IGSTK has established practices and standards for quality. The practices have been described throughout this paper, from traditional techniques like code reviews to agile techniques such as pervasive unit testing.

44. IGSTK Discussions Designs should be kept simple: IGSTK’s design is simple; in fact simplicity is an overriding agile principle. Component designs share a common architecture pattern (the state machine), and design principles are enforced in code through strongly-typed interfaces and specific macros. Designs are documented and discussed on the Wiki.

45. IGSTK Discussions Ways to get information about errors - for example, software audit trails – should be designed into the software from the beginning: IGSTK’s logging facility records each request and response in the system, providing a full audit trail. The lightweight requirements management process ensures lockstep requirement and code changes.

46. IGSTK Discussions The software should be subjected to extensive testing and formal analysis at the module and software level; system testing alone is not adequate: IGSTK is rigorously tested at the unit level on a continuous basis. Formal analysis is incorporated into the agile process through a validation suite that reports results directly to the dashboard.

47. Open-do: an open-source initiative for the development of safety-critical software by: C. Comar, F. Gasperoni, J.F. Ruiz Presented by: Tim Fleck

48. Open-do initiative • Open as in “open • DO as in DO-178C, an aviation standard for airborne software • Goal of increasing the agility and automation in the production of safety-critical software • Focuses on more continuous and incremental certification • Emphasis on open source tools and materials

49. Safety critical development issues • Time and budget pressure • Need to meet the highest levels of safety • Must comply with stringent standards • Some activities are tedious, labor-intensive, and error prone

50. Open-Do Goals • Address the big freeze problem • Ensure wide and long-term availability of qualified open source tools and certifiable components • Decrease barrier of entry • Encourage re-search • Increase availability of educational material • Foster cross-fertilization between open-source and safety-critical software communities