Posts Tagged ‘Thoughtworks’
[OxidizeConf2024] Safety Compliance of Rust Libraries
Navigating Automotive Safety Standards
The automotive industry’s shift toward software-defined vehicles has intensified the need for robust safety compliance, particularly for software components used in safety-critical applications. At OxidizeConf2024, Amit Dharmapurikar and Gnana Ganesh from Thoughtworks delivered an insightful presentation on qualifying Rust libraries for compliance with ISO 26262, a standard governing functional safety in automotive systems. With Thoughtworks’ expertise in software-defined vehicles, Amit and Gnana provided a comprehensive overview of the processes and tools required to ensure Rust libraries meet stringent safety requirements, focusing on the Rust Core library as a case study.
ISO 26262 mandates rigorous documentation, requirement coverage, and structural code coverage to ensure software reliability in electronic control units (ECUs). Amit emphasized that while the Ferrocene compiler, developed by Ferrous Systems, has already achieved safety compliance, libraries—both standard and third-party—must also be qualified. This involves producing formal specifications, verifying requirements through testing, and generating code coverage reports. The speakers highlighted the collaborative effort with Ferrous Systems to qualify the Rust Core library, underscoring the importance of aligning open-source tools with automotive standards.
Documentation and Requirement Coverage
A cornerstone of ISO 26262 compliance is comprehensive documentation, which serves as a formal specification of software components. Gnana detailed how Thoughtworks approaches this by deriving testable requirements from the Rust Core library’s standard documentation. This process involves translating descriptive text into precise, verifiable requirements, a task that poses challenges due to the library’s frequent updates as an open-source project. To address this, Amit and Gnana proposed developing tools to automate the interpretation of documentation changes, ensuring that requirements remain aligned with the library’s evolution.
Requirement coverage, as mandated by ISO 26262 Part 6, ensures that all functional requirements are tested. The speakers demonstrated a proof-of-concept where requirements for the Rust Core library were linked to test cases, providing traceability essential for audits. This approach leverages open-source tools like Sphinx, which facilitates bidirectional traceability by connecting requirements to code. By integrating these tools into the development pipeline, Thoughtworks ensures that compliance artifacts are generated iteratively, reducing manual effort and enhancing accountability.
Advancing Code Coverage with Rust Tooling
Structural code coverage is another critical aspect of ISO 26262 compliance, requiring developers to measure how thoroughly code is exercised by tests. Amit showcased a demo using the Rust toolchain’s coverage capabilities, specifically the --coverage flag in the test subcommand. This flag, combined with a custom bootstrap command (dotx), embeds profiler builtins into executables, generating profile files that tools like grcov process into coverage reports. The demo illustrated coverage analysis for the Rust Core library, excluding documentation to focus on executable code.
While statement coverage is already supported, Gnana noted that branch coverage is available in draft pull requests, and Modified Condition/Decision Coverage (MCDC) is in progress within the Rust community. These advancements, driven by initiatives like Ferrocene, demonstrate Rust’s growing maturity for safety-critical applications. The speakers acknowledged challenges, such as managing frequent library updates, but emphasized the potential of automated tools to streamline compliance, making Rust a viable choice for automotive software development.
Links:
[DevoxxUK2024] How We Decide by Andrew Harmel-Law
Andrew Harmel-Law, a Tech Principal at Thoughtworks, delivered a profound session at DevoxxUK2024, dissecting the art and science of decision-making in software development. Drawing from his experience as a consultant and his work on a forthcoming book about software architecture, Andrew argues that decisions, both conscious and unconscious, form the backbone of software systems. His talk explores various decision-making approaches, their implications for modern, decentralized teams, and introduces the advice process as a novel framework for balancing speed, decentralization, and accountability.
The Anatomy of Decision-Making
Andrew begins by framing software architecture as the cumulative result of myriad decisions, from coding minutiae to strategic architectural choices. He introduces a refined model of decision-making comprising three stages: option making, decision taking, and decision sharing. Option making involves generating possible solutions, drawing on patterns, stakeholder needs, and past experiences. Decision taking, often the most scrutinized phase, requires selecting one option, inherently rejecting others, which Andrew describes as a “wicked problem” due to its complexity and lack of a perfect solution. Decision sharing ensures effective communication to implementers, a step frequently fumbled when architects and developers are disconnected.
Centralized Decision-Making Approaches
Andrew outlines three centralized decision-making models: autocratic, delegated, and consultative. In the autocratic approach, a single individual—often a chief architect—handles all stages, enabling rapid decisions but risking bottlenecks and poor sharing. Delegation involves the autocrat assigning decision-making to others, potentially improving outcomes by leveraging specialized expertise, though it remains centralized. The consultative approach sees the decision-maker seeking input from others but retaining ultimate authority, which can enhance decision quality but slows the process. Andrew emphasizes that while these methods can be swift, they concentrate power, limiting scalability in large organizations.
Decentralized Decision-Making Models
Transitioning to decentralized approaches, Andrew discusses consent, democratic, and consensus models. The consent model allows a single decision-maker to propose options, subject to veto by affected parties, shifting some power outward but risking gridlock. The democratic model, akin to Athenian direct democracy, involves voting on options, reducing the veto power of individuals but potentially marginalizing minority concerns. Consensus seeks universal agreement, maximizing inclusion but often stalling due to the pursuit of perfection. Andrew notes that decentralized models distribute power more widely, enhancing collaboration but sacrificing speed, particularly in consensus-driven processes.
The Advice Process: A Balanced Approach
To address the trade-offs between speed and decentralization, Andrew introduces the advice process, a framework where anyone can initiate and make decisions, provided they seek advice from affected parties and experts. Unlike permission, advice is non-binding, preserving the decision-maker’s autonomy while fostering trust and collaboration. This approach aligns with modern autonomous teams, allowing decisions to emerge organically without relying on a fixed authority. Andrew cites the Open Agile Architecture Framework, which supports this model by emphasizing documented accountability, such as through Architecture Decision Records (ADRs). The advice process minimizes unnecessary sharing, ensuring efficiency while empowering teams.
Navigating Power and Accountability
A recurring theme in Andrew’s talk is the distribution of power and accountability. He challenges the assumption that a single individual must always be accountable, advocating for a culture where teams can initiate decisions relevant to their context. By involving the right people at the right time, the advice process mitigates risks associated with uninformed decisions while avoiding the bottlenecks of centralized models. Andrew’s narrative underscores the need for explicit decision-making processes, encouraging organizations to cultivate trust and transparency to navigate the complexities of modern software development.
Links:
[OxidizeConf2024] Continuous Compliance with Rust in Automotive Software
Introduction to Automotive Compliance
The automotive industry, with its intricate blend of mechanical and electronic systems, demands rigorous standards to ensure safety and reliability. Vignesh Radhakrishnan from Thoughtworks delivered an insightful presentation at OxidizeConf2024, exploring the concept of continuous compliance in automotive software development using Rust. He elucidated how the shift from mechanical to software-driven vehicles has amplified the need for robust compliance processes, particularly in adhering to standards like ISO 26262 and Automotive SPICE (ASPICE). These standards are pivotal in ensuring that automotive software meets stringent safety and quality requirements, safeguarding drivers and passengers alike.
Vignesh highlighted the transformation in the automotive landscape, where modern vehicles integrate complex software for features like adaptive headlights and reverse assist cameras. Unlike mechanical components with predictable failure patterns, software introduces variability that necessitates standardized compliance to maintain quality. The presentation underscored the challenges of traditional compliance methods, which are often manual, disconnected from development workflows, and conducted at the end of the development cycle, leading to inefficiencies and delayed feedback.
Continuous Compliance: A Paradigm Shift
Continuous compliance represents a transformative approach to integrating safety and quality assessments into the software development lifecycle. Vignesh emphasized that this practice involves embedding compliance checks within the development pipeline, allowing for immediate feedback on non-compliance issues. By maintaining documentation close to the code, such as requirements and test cases, developers can ensure traceability and accountability. This method not only streamlines the audit process but also reduces the mean-time-to-recovery when issues arise, enhancing overall efficiency.
The use of open-source tools like Sphinx, a Python documentation generator, was a focal point of Vignesh’s talk. Sphinx facilitates bidirectional traceability by linking requirements to code components, enabling automated generation of audit-ready documentation in HTML and PDF formats. Vignesh demonstrated a proof-of-concept telemetry project, showcasing how Rust’s cohesive toolchain, including Cargo and Clippy, integrates seamlessly with these tools to produce compliant software artifacts. This approach minimizes manual effort and ensures that compliance is maintained iteratively with every code commit.
Rust’s Role in Simplifying Compliance
Rust’s inherent features make it an ideal choice for automotive software development, particularly in achieving continuous compliance. Vignesh highlighted Rust’s robust toolchain, which includes tools like Cargo for building, testing, and formatting code. Unlike C or C++, where developers rely on disparate tools from multiple vendors, Rust offers a unified, developer-friendly environment. This cohesiveness simplifies the integration of compliance processes into continuous integration (CI) pipelines, as demonstrated in Vignesh’s example using CircleCI to automate compliance checks.
Moreover, Rust’s emphasis on safety and ownership models reduces common programming errors, aligning well with the stringent requirements of automotive standards. By leveraging Rust’s capabilities, developers can produce cleaner, more maintainable code that inherently supports compliance efforts. Vignesh’s example of generating traceability matrices and architectural diagrams using open-source tools like PlantUML further illustrated how Rust can enhance the compliance process, making it more accessible and cost-effective.
Practical Implementation and Benefits
In his demonstration, Vignesh showcased a practical implementation of continuous compliance using a telemetry project that streams data to AWS. By integrating Sphinx with Rust code, he illustrated how requirements, test cases, and architectural designs could be documented and linked automatically. This setup allows for real-time compliance assessments, ensuring that software remains audit-ready at all times. The use of open-source plugins and tools provides flexibility, enabling adaptation to various input sources like Jira, further streamlining the process.
The benefits of this approach are manifold. Continuous compliance fosters greater accountability within development teams, as non-compliance issues are identified early. It also enhances flexibility by allowing integration with existing project tools, reducing dependency on proprietary solutions. Vignesh cited the Ferrocene compiler as a real-world example, where similar open-source tools have been used to generate compliance artifacts, demonstrating the feasibility of this approach in large-scale projects.