Verification is planned with development for each software lifecycle phase and documented, referring to criteria, techniques and tools and addressing evaluation of safety integrity requirements, choice and recording of strategies, activities and techniques, verification tools (test harnesses, simulators), evaluation of results and corrective action. It is performed as planned, with evidence that each phase was completed satisfactorily. Each verification records the items verified, the information verified against, and non-conformances. Everything from phase N that phase N+1 needs is available and verified, covering adequacy of the specification, design or code for functionality, integrity and performance, readability, testability and safe modification; adequacy of the tests specified for phase N; and incompatibilities between phase N tests and those of phase N-1 and among phase N outputs. Depending on the lifecycle chosen, verification covers software safety requirements, architecture, system design, module design, code, data, timing performance, module testing, integration testing, PE integration testing and validation. Requirements verification, before design begins, checks the software safety requirements fulfil the system safety requirements and that the validation plan fulfils the software requirements, and checks incompatibilities between them. Architecture, system design and module design verification each check that the design fulfils the level above, that its integration or module tests are adequate, that element or module attributes support safety performance, testability, readability and safe modification, and that the design, the level above and the tests are mutually compatible. Code is verified by static methods against the module design, coding standards and validation plan. Data verification covers data structures; application data for consistency, completeness, compatibility and correct values; operational parameters against application requirements; plant interfaces for detecting and tolerating anticipated failures; and communication interfaces for failure detection, corruption protection and data validation. Timing behaviour is verified as predictable.
This control maps to 2 controls across 2 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 2 it maps to, and the evidence behind each claim, over MCP and REST.