Take a faster, smarter path to AI-driven C/C++ test automation. Discover how >>
Whitepaper
Curious what’s in the whitepaper? Start with the overview below.
Safety functions in industrial automation are increasingly executed by complex electrical, electronic, and programmable electronic systems. Testing these systems is essential but challenging due to their complexity. IEC 61508 provides guidance to reduce systematic and random hardware failure risks to tolerable levels.
This whitepaper details how Parasoft helps software development teams meet SIL requirements, introducing the concept of SIL as defined by IEC 61508, describing Parasoft’s integrated solution for automating best practices, and showing how to satisfy software development process requirements for specific SIL levels.
Safety Integrity Level (SIL)—defined by the IEC 61508 standard—is one of four levels (SIL1-SIL4) corresponding to the range of a given safety function’s target likelihood of dangerous failures. Each safety function in a safety-related system needs to have appropriate safety integrity level assigned. An E/E/PE safety-related system will usually implement more than one safety function. If the safety integrity requirements for these safety functions differ, unless there is sufficient independence of implementation between them, the requirements applicable to the highest relevant safety integrity level shall apply to the entire E/E/PE safety-related system.
According to IEC 61508, the safety integrity level for a given function is evaluated based on either the average probability of failure to perform its design function on demand (for a low demand mode of operation) or on the probability of a dangerous failure per hour (for a high demand or continuous mode of operation).
The IEC 61508 standard specifies the requirements for achieving each safety integrity level. These requirements are more rigorous at higher levels of safety integrity in order to achieve the required lower likelihood of dangerous failures.
Parasoft C/C++test is an integrated solution for automating a broad range of best practices proven to improve software development team productivity and software quality. C/C++test facilitates:
This provides teams a practical way to prevent, expose, and correct errors in order to ensure that their C and C++ code works as expected. To promote rapid remediation, each problem detected is prioritized based on configurable severity assignments, automatically assigned to the developer who wrote the related code, and distributed to his or her IDE with direct links to the problematic code and a description of how to fix it.
For embedded and cross-platform development, C/C++test can be used in both host-based and target-based code analysis and test flows.
Parasoft C/C++test’s automation greatly increases the efficiency of testing the correctness and reliability of newly developed or legacy code. C/C++test automatically generates complete tests, including test drivers and test cases for individual functions, purely in C or C++ code. These tests, with or without modifications, are used for initial validation of the functional behavior of the code. By using corner case conditions, these automatically-generated test cases also check function responses to unexpected inputs, exposing potential reliability problems.
Parasoft C/C++test’s HTML, PDF, and custom format reports can be configured via GUI controls or an options file. The standard reports include a pass/fail summary of code analysis and test results, a list of analyzed files, and a code coverage summary. The reports can be customized to include a listing of active static analysis checks, expanded test output with pass/fail status of individual tests, parameters of trend graphs for key metrics, and full code listings with color-coding of all code coverage results.
Code analysis and test results, coverage analysis, and other C/C++test data can be sent to Parasoft DTP where it’s correlated with data generated by third-party analyzers, source control, defect tracking, and other infrastructure components and processed by DTP. The result is actionable, intelligent analytics that not only provide visibility into the risk associated with the application under test, but also the traceability required to achieve SIL requirements.
The following tables describe how Parasoft C/C++test supports the software development life cycle methods required for safety functions to achieve a given SIL. Please note that the information presented here is meant to briefly introduce C/C++test usage in the SIL-related verification and testing process. Please refer to the standard and consult functional safety experts for clarification of any requirements defined by the IEC 61508 standard. If you have any additional questions regarding how to use C/C++test in the IEC 61508 certification process, please contact your Parasoft representative.
The following markers are used in the tables presented below to indicate:
Techniques and measures defined annex A and B of IEC 61508-3 edition 2.0 2010 that are satisfied by C/C++test functionality have been captured in the tables below.
| C/C++test Functionality | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Design and Coding Standards | ||||
| Use of coding standard to reduce likelihood of errors (Table B.1: 1) | — | R | HR | HR |
| No dynamic objects (Table B.1: 2) | R | HR | HR | HR |
| No dynamic variables (Table B.1: 3a) | — | R | HR | HR |
| Online checking of the installation of dynamic variables (Table B.1: 3b) | — | R | HR | HR |
| Limited use of interrupts (Table B.1: 4) | R | R | HR | HR |
| Limited use of pointers (Table B.1: 5) | — | R | HR | HR |
| Limited use of recursion (Table B.1: 6) | — | R | HR | HR |
| No unstructured control flow in programs in higher level languages (Table B.1: 7) | R | HR | HR | HR |
| No automatic type conversion (Table B.1: 8) | R | HR | HR | HR |
| Dynamic Analysis and Testing | ||||
| Test case execution from boundary value analysis (Table B.2: 1) | R | HR | HR | HR |
| Test case execution from error guessing (Table B.2: 2) | R | R | R | R |
| Test case execution from error seeding (Table B.2: 3) | — | R | R | R |
| Equivalence classes and input partition testing (Table B.2: 6) | R | R | R | HR |
| Structural test coverage (entry points) 100% (Table B.2: 7a) | HR | HR | HR | HR |
| Structural test coverage (statements) 100% (Table B.2: 7b) | R | HR | HR | HR |
| Structural test coverage (branches) 100% (Table B.2: 7c) | R | R | HR | HR |
| Structural test coverage (conditions, MC/DC) 100% (Table B.2: 7d) | R | R | R | HR |
| Functional and Black Box Testing | ||||
| Equivalence classes and input partition testing, including boundary value analysis (Table B.3: 4) | R | HR | HR | HR |
| Performance Testing | ||||
| Avalanche/stress testing (Table B.6: 1) | R | R | HR | HR |
| Static Analysis | ||||
| Boundary value analysis (Table B.8: 1) | R | R | HR | HR |
| Checklists (Table B.8: 2) | R | R | R | R |
| Control flow analysis (Table B.8: 3) | R | HR | HR | HR |
| Data flow analysis (Table B.8: 4) | R | HR | HR | HR |
| Error guessing (Table B.8: 5) | R | R | R | R |
| Formal inspections, including specific criteria (Table B.8: 6a) | R | R | HR | HR |
| Walk-through (software) (Table B.8: 6b) | R | R | R | R |
| Symbolic execution (Table B.8: 7) | — | — | R | R |
| Design review (Table B.8: 8) | HR | HR | HR | HR |
| Static analysis of run time error behaviour (Table B.8: 9) | R | R | R | HR |
| Modular Approach | ||||
| Software module size limit (Table B.9: 1) | HR | HR | HR | HR |
| Software complexity control (Table B.9: 2) | R | R | HR | HR |
| C/C++test Functionality | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Software Architecture Design | ||||
| Fault detection (Table A.2: 1) | — | R | HR | HR |
| Diverse monitor techniques (with separation between the monitor computer and the monitored computer) (Table A.2: 3c) | — | R | R | HR |
| Diverse redundancy, implementing the same software safety requirements specification (Table A.2: 3e) | — | — | — | R |
| Use of trusted/verified software elements (if available) (Table A.2: 8) | R | HR | HR | HR |
| Support Tools and Programming Language | ||||
| Suitable programming language (Table A.3: 1) | HR | HR | HR | HR |
| Strongly typed programming language (Table A.3: 2) | HR | HR | HR | HR |
| Language subset (Table A.3: 3) | — | — | HR | HR |
| Certified tools and certified translators (Table A.3: 4a) | R | HR | HR | HR |
| Tools and translators: increased confidence from use (Table A.3: 4b) | HR | HR | HR | HR |
| Detail Design | ||||
| Structured methods (Table A.4: 1a) | HR | HR | HR | HR |
| Formal design and refinement methods (Table A.4: 1c) | — | R | R | HR |
| Defensive programming (Table A.4: 3) | — | R | HR | HR |
| Modular approach (Table A.4: 4) | HR | HR | HR | HR |
| Design and coding standards (Table A.4: 5) | R | HR | HR | HR |
| Structured programming (Table A.4: 6) | HR | HR | HR | HR |
| Use of trusted/verified software elements (Table A.4: 7) | R | HR | HR | HR |
| Forward traceability between the software safety requirements specification and software design (Table A.4: 8) | R | R | HR | HR |
| Software Module Testing and Integration | ||||
| Dynamic analysis and testing (Table A.5: 2), (Table A.9: 4) | R | HR | HR | HR |
| Data recording and analysis (Table A.5: 3) | HR | HR | HR | HR |
| Functional and black box testing (Table A.5: 4)(Table A.7: 4) | HR | HR | HR | HR |
| Interface testing (Table A.5: 7) | R | R | HR | HR |
| Test management and automation tools (Table A.5: 8) | R | HR | HR | HR |
| Forward traceability between the software design specification and the module and integration test specifications (Table A.5: 9) | R | R | HR | HR |
| Formal verification (Table A.5: 10) | — | — | R | R |
| Modification | ||||
| Reverify changed software module (Table A.8: 2) | HR | HR | HR | HR |
| Reverify affected software module (Table A.8: 3) | R | HR | HR | HR |
| Revalidate complete system (Table A.8: 3) | — | R | HR | HR |
| Regression validation | R | HR | HR | HR |
| Software Verification | ||||
| Formal proof | — | R | R | HR |
| Static analysis | R | HR | HR | HR |
| Dynamic analysis and testing (Table A.5: 2), (Table A.9: 4) | R | HR | HR | HR |
| Forward traceability between the software design specification and the software verification (including data verification) plan | R | R | HR | HR |
| Backward traceability between the software verification (including data verification) plan and the software design specification | R | R | HR | HR |
| C/C++test Functionality | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Hardware and Software | ||||
| Functional and black box testing (Table A.6: 1) | HR | HR | HR | HR |
| Forward traceability between the system and software design requirements for hardware/software integration and the hardware/software integration test specification (Table A.6: 3) | R | R | HR | HR |
| C/C++test Functionality | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Parasoft DTP’s Reporting and Analytics Dashboard | ||||
| Forward traceability between the system safety requirements and the software safety requirements (Table A.1:2) | R | R | HR | HR |
| Backward traceability between the safety requirements and the perceived safety needs (Table A.1:3) | R | R | HR | HR |
| Computer-aided specification tools to support appropriate techniques/measures above (Table A.1:4) | R | R | HR | HR |
Parasoft C/C++test helps software development teams meet the functional safety requirements of IEC 61508. A broad range of analysis types—including coding standards compliance analysis, data and control flow analysis, unit testing, application monitoring, workflow components, and peer code review process—together with the configurable test reports containing high level of details, significantly facilitates the work required for the software verification process.
Ready to dive deeper?
