Agile Methods for Open Source Safety-Critical Software

by: Kevin Gary, Andinet Enquobahrie, Luis Ibanez, Patrick Cheng, Ziv Yaniv, Kevin Cleary,Shylaja Kokoori,Benjamin Muffih, and John Heidenreich

Presented by: Tim Fleck

Most of the material presented is directly attributed to the authors of the topic paper

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...

Safety Critical SystemsAnti-lock BreaksNuclear Control Systems9-1-1 DispatchFire AlarmsInsulin PumpsRoller Coaster ControllersAvionicsImage-Guided Surgical

ToolKit(IGSTK)

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

IntroductionStarting 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

Agile and Open SourceOpen Source often employs Agile

methods◦Concurrent development◦Fast sprints◦Gated production

OSSD also uses highly skilled distributed volunteers with no singularly available customer

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.”

Image-Guided Surgical Toolkit (IGSTK)Open Source ProjectProvides 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.”

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

AgileScrumXPSprintIterationMethodology

Discussion?

BackgroundAccording 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”.

Engineering Safety Critical Systems

High levels of assuranceTesting Other methods of

checking(validation, inspection, ???)Prevent malicious actionsConcern for inadvertent actions

Thoughts Against AgileFrom Barry Boehm’s paper they

reference

No stable requirementsInsufficient planning

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

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.

Author’s Response – Don’t Overlook the TeamSoftware is the output of a

human-oriented processThe 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).

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.

Gelowitz et 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.

IGSTK OverviewMany 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

IGSK Process challenges

Framework requirements can’t be fully understood until applications constructed

Use cases selectively useful for similar reasons

IGSK Process challengesDistributed team of academic

and commercial collaborators.

Challenges setting expectations and deliverables.

IGSK Process challengesHigh quality standards

End of sprint code reviews

OS patterns of code releases

Architecture ChallengesCreating a safe platform - State machine

design

Maintaining good communication practices

Strong central design patter amid strong open source evolutionary principles.

Minimizing configurability

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.

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

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.

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.

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.

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.

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.

Best Practices - 6

Emphasize continuous builds and testing. IGSTK uses the open source CDash tool 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.

Best Practices - 7Support the process with open

tools. IGSTK uses CDash, a test dashboard, CMake, a cross-platform build solution, and Doxygen, a documentation system.

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.

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.

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.

Best PracticesNone of these new to Open Source

or Agile practitionersInsufficient in themselves for

safety-critical systemsIGSK expands on 4 areas

◦lightweight requirements management (#8)

◦safety-by-design (#9)◦continuous integration and testing (#6)◦architecture validation (#5)

Requirements managementDevelopers introduce new

requirements into backlogCollaborative process for

reviewing, implementing, validating and archiving◦Initialized and defined◦Rejected/Aborted or accepted by

team decision◦Verified when implemented and

functionally confirmed

Safety by DesignState machine with strong

encapsulationIGSTK 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.

Continuous Integration and TestingIGSTK relies heavily on the agile

practice of continuous and extensive unit testing with automated tool support.

Ctest tool which posts to CdashTests from systems around the

globeOS provides a global community

of early adopters

Architecture Validationvalidation tool suite is a simulator that

accepts descriptions of state machines in SCXML reverse engineered from the source code

Tool created by projectDesign done via Wiki and modeling

constructed within the source codeThe validation suite of tools checks the

fidelity of the model’s representation and execution semantics

SafetyDifficult 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,

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.

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.

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.

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.

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.

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

Open-do initiativeOpen as in “openDO as in DO-178C, an aviation

standard for airborne softwareGoal 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

Safety critical development issuesTime and budget pressureNeed to meet the highest levels

of safetyMust comply with stringent

standardsSome activities are tedious,

labor-intensive, and error prone

Open-Do GoalsAddress the big freeze problemEnsure wide and long-term availability

of qualified open source tools and certifiable components

Decrease barrier of entryEncourage re-searchIncrease availability of educational

materialFoster cross-fertilization between open-

source and safety-critical software communities

The big freezeWhen an application is complete

and certified, evolution becomes costly

After receiving the certified stamp, later changes avoided; called the “big freeze”

“big freeze” can occur at the system level as well

Continuous certificationContinuous integration

◦All elements of application maintained in a repository

◦Automated building and self testing◦All changes trigger rebuild and

testing◦Testing done in production

environment◦Results visible to anyone

Continuous certificationBenefits

◦Defects identified early◦Integrations issues detected early◦Newcomers benefit from exhaustive

automated testing◦Quality stays high eliminated need

for long verification phases

Enhanced continuous certificationRepository contains the software

as well as high and low-level requirements, test cases, documentation and certification artifacts

Most certification activities are automated

Every change triggers a complete run of activities allowing faster certification

Qualifiable open source toolsMost tools are restricted by

availability, cost or expected lifespan

Open source tools with qualifications would increase their audience and decrease the cost of creation and increase re-use

Airbus’s TOPCASED and Boeing’s OSSE are examples of these possibilities

Open-do viabilityOpen-DO must give rise to a

viable ecosystem to be sustainable

Contributions must come from all parties; industrial, vendors, certification authorities, universities and public institutions

Open source provides the ideal choice for such a collaboration effort