Developing Open-Source Software RTOS with Functional Safety in Mind - Anas Nashif, Intel (Zephyr)

Software
1

See also:

Notes:

  • difficult to map a stereotypical open-source development to the V-model
  • certification authority not familiar with open-source development
  • V-model
    • requires a lot of process and documentation
    • need to start transforming your development model
  • Quality Matters
    • coverage, documentation, testing, test reports
    • Quality is a foundation, base requirement
  • Requirement Traceability
  • Traceability Tools
    • every line of code is connected to requirements, testing, test reports
    • we don’t do in open source projects
    • Currently used in Zephyr
      • Doxygen
      • tests
      • requirements
      • able to connect some of the requirements
  • MISRA-C
    • style guide
    • focus in safety, security, portability, and reliability
    • contains 167 + 14 guidelines
    • a lot of rules make a lot of sense, but some are not well received
    • having a consistent style helps with quality and readability
    • opensource challenges
      • MISRA-C is proprietary
      • Most CI tools are commercial and not easy to integrate into Github/PRs
    • Zephyr integrated check-patch from Linux kernel – give feedback about code immediately
    • decide which parts of the code are important to you
    • example of a controversial rule
      • Rule 15.5 - a function should have a single point of exit at the end
    • changing existing code structure adds risk
  • Users demand Accountability
    • Feature richness and completeness is not enough
    • Main reason why adoption of open source is limited for higher safety integrity levels: “who is liable if something goes wrong?”
  • How to approach certification in open-source
    • Snapshot/branch
    • getting supported feature set right up front
      • every line of cost costs $150-$200
    • Automate as much of the information tracking as you can
    • Auto-generate documents from test and issue tracking systems
  • The Ideal Project
    • split development model
      • Flexible open instance
      • Auditable and controlled instance - branch with well defined scope developed with stricter rules and with an entity behind it
    • SafeRTOS (FreeRTOS fork) did something similar, not quite
      • was rebuilt and rewritten
      • not the ideal model for open-source
      • Zephyr wants to keep it OSS
  • Example: Regulating the Bazaar
    • do we have the right set of reviewers?
    • who gets to have the final say?
    • how do we guarantee that the reviewer is aware of safety implications?
    • for how long should changes be reviewed?
  • Pull Request Processing Time
    • wait at least a few days to merge code so it can be reviewed
  • Contributions vs Reviews
    • people like to contribute but not review
  • Zephyr
  • Architecture and Key Features
    • highly configurable, highly modular
    • cooperative and pre-emptive threading
    • memory and resources are typically statically allocated
    • memory protection: stack overflow protection, kernel object and device driver permission tracking, thread issolation
  • Roadmap
    • limit scope
    • robustness and operation safety
      • mmu and mpu support
      • tread isolation
      • stack protection
    • enhance and increase test coverage
    • compliance with coding and style guidelines
      • MISRA-C
    • well defined and stable APIs
    • Portability
      • support POSIX APIs
  • Scope for FuSA
    • only kernel and core parts would be certified
  • LTS release
  • Summary
    • functional safety and security requirements need to coexist with the open-source nature of the project
    • quality needs to be driven on the project level
    • manage developer and contributor expectations
    • continue innovating on the main tree while hardening and stabalizing LTS
    • need to officially establish accountability and trusted “entity”, ie with Certification Architect role of the project
  • Q&A
    • Q: was asked if Zephyr has been deployed into safety critical systems
    • A: Yes, but I can’t talk about it, but confirmed there are already users in these applications.
    • Zephyr is something you can innovate on instead of depending on 3rd party vendors/solutions.
    • Q: how do you unittest the core features, interrupt handlers, etc.
    • A: most of the testing is done a component level.
    • Q: can you Zephyr on top of a certified hypevisor
    • A: yes, that is possible