Aim: an architecture that achieves the software requirements; identification and evaluation of how much hardware and software interactions matter for safety; choice of a design method if none is set; design at the defined integrity level; and software that is readily testable from the start, with verification and test needs considered throughout. From the Software Requirements Specification the phase produces the architecture, design and interface specifications, the two integration test specifications (software alone, and software with hardware) and the architecture and design verification report. The Designer's architecture specification, as Table A.1 requires, sets out the architecture; judges feasibility at the level (keeping the safety part small and simple); analyses every hardware/software interaction; lists every component as new or existing, previously validated or not (with its conditions) and its integrity level; each component covers a defined requirements subset and is separately versioned. Pre-existing software: at every level its intended requirements, environment assumptions and interfaces are documented and it is included in whole-software validation; at SIL 3 and 4 its failures and their consequences are analysed, a detection and protection strategy is defined, and verification and validation confirm it meets its requirements, its failures are caught and contained and its environment assumptions hold; it comes with a precise and complete description of functions, constraints and evidence for designers and testers; statistical evidence may support its validation. Verified components built to this standard are preferred. Mixed-level components are all handled at the highest level unless non-interference is evidenced and recorded, with the interference-control parts at the highest level; such evidence should cover spatial and temporal separation, timing and sequence, data access, data exchange integrity, authenticity, order and timeliness, shared hardware, the ability to reach a safe state in time, and completeness of the measures. The architecture specification describes the development strategy per Table A.3, is complete, consistent, clear, precise, unambiguous, verifiable, testable, maintainable, feasible and traceable to the requirements, includes fault handling to balance fault avoidance, and justifies the techniques, measures and tools as a sufficient set; generic software and application data are rigidly separated so either can be rebuilt without the other, and installation-specific data kept apart from generic data. Prototyping may elicit requirements, but prototype code enters the target only if it and its documentation meet the standard. The interface specification covers all internal and boundary interfaces (only the boundary at Basic Integrity) and application data where relevant: pre and post conditions, boundary values and behaviour at and beyond them, timing constraints and exception handling for time-critical data, buffer memory and full-buffer detection, synchronisation, and every value range of each data type with equivalence classes including unused or forbidden ones. The design specification decomposes into components each with a component design and test specification and covers components traced to the architecture with their levels, interfaces with the environment and each other, data structures, requirement allocation, main algorithms and sequencing, error reporting, and the software to application-data interface, detecting corrupted application data where feasible, using Table A.4 techniques. A programming language is chosen against Table A.15; coding standards set good practice per Table A.12, guard against language pitfalls that verification would not catch (from an analysis of all language features) and set source documentation rules, are justified for the level, apply to all software and are cited in the quality plan. The design method supports abstraction and modularity, clear expression of function, information flow, sequencing and timing, concurrency and data, comprehension, verification and maintenance. The Tester writes the software integration test specification (components exercised together through their interfaces, out-of-specification inputs, input and output sequences and values, reuse of component test results, Table A.6) and, where Table A.1 requires, the software/hardware integration test specification, started early, separating supplier-premises and user-site activities, and showing correct running on the hardware interfaces, handling of hardware faults, timing and performance, with its test cases, types, environment and completion criteria. The Verifier's report checks internal consistency, adequacy against the requirements, readability, traceability and specific content of each specification, the handling of hardware and software constraints, and both integration test specifications.
This control maps to 14 controls across 4 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 14 it maps to, and the evidence behind each claim, over MCP and REST.