getting existing projects through iec615081. develop a new product using the iec61508 standard 2....

V1.0 Page | 1

www.hitex.co.uk [email protected] 024 7669 2066

Getting existing projects through IEC61508 Written by the Safety Team, Hitex UK

The drive for improving the safety of embedded systems is now well advanced in the automotive world with the release of ISO26262. This has been driven by the need to reduce service costs and avoid

product liability claims, against the background of a massive increase in the deployment of microcontroller-based systems. ISO26262 is essentially the automotive version of IEC61508, which allows the concept of an intelligent user, capable of preventing some failures becoming life-threatening, being part of the safety case. It also takes account of the fact that the car industry produces millions of products containing programmable devices, rather than just a small number of very large items like a power station. IEC61508 dates from 1998 and was adopted by some parts of the industrial controls sector in the early 2000s (e.g. process control, railway, medical). However, the majority of manufacturers did not adopt it straight away. As a result, there are a huge number of industrial control systems in current production which were engineered outside of the standard. Some of the industries which adopted it early went on to create their own customised versions e.g. IEC61511 (process control) and EN50128/9 (railways), IEC61513 (nuclear industry), IEC615800-5-2 (variable speed motor drives). The surprising thing is that even though IEC61508 is 14 years older than ISO26262, the impetus to adopt it has been much less, so whilst almost all automotive manufacturers and their component suppliers are fully conversant with ISO26262, in the industrial world the IEC61508 take-up rate is much lower. However, in certain areas the need to use IEC61508 is becoming urgent. For example, motor drives now often need to be SIL2 or SIL3 and to sell into certain applications. For example, machine operators could be permanently injured by any unintended motor operation, so any motor drive in the machine must be certified at SIL2. Thus any previously existing motor controller used can no longer be fitted. The manufacturer of that controller then has three choices:

1. Develop a new product using the IEC61508 standard 2. Try to continue to sell the original product 3. Try to retrospectively apply IEC61508 to the existing product

IEC61508 specifies the entire development process, along with the development techniques to be used. Any certification of the product will involve an assessment of the development process. Thus if the drive was not developed “the right way”, on the face of it, it is not possible to retrospectively get the product certificated.

V1.0 Page | 2


However this is not entirely true. IEC61508 does allow the use of existing code provided that it is “proven in use” or has “increased confidence from use”. To show this in reality is difficult, but IEC61508-7, Annex D describes a probabilistic approach to determining software safety integrity for pre-developed software which could be applied to older systems. Reliability data for an existing product needs to be gathered over a long period – at least several years for a high volume product across many installations. Gathering this information is not easy, as it has to be based on field returns, warranty data, customer feedback - all sources which can be hard to verify. The problem here is that an older product which might have a long and reliable track record will probably have a basic hardware design nearing end-of-life and therefore would not be a good platform on which to spend a lot of money getting IEC61508 certification. A newer product with a design that warrants further investment will almost certainly not have the reliability data to hand. In the latter case, it is acceptable to effectively take the system apart and then put it back together again using an IEC61508 approach to the development process and the techniques used. How this can be done in detail is covered later on. Use of this existing code is likely to require applying or creating new diagnostic requirements to monitor and verify the integrity of the software's output functions. For example, does the existing system have some kind of monitoring mechanism to verify that the CPU clock is correct, or that the application is running as intended and does that mechanism have the ability to put the safety-related outputs into a safe state? In a recent design, these safety functions may already exist and simply need to be put into an IEC61508 safety context. Where they are not present they will have to be added. In either case tests will need to be added to a validation plan, to ensure that the software meets the product and safety requirements. Thus the possibility of applying IEC61508 retrospectively does exist, but in some cases doing so is prohibitively expensive and may actually cost more than re-engineering the product again from scratch. This is especially true if the existing project is very poorly documented, has no proper unit tests, or has to be at a high Safety Integrity Level (SIL) i.e. SIL3. However, for most professionally-conducted projects that need to be SIL2, it is often feasible to apply IEC61508, but there is likely to be a significant cost in money and man power. This paper looks at the issues that have to be addressed when trying to apply IEC61508 SIL2 or 3 to an existing product from the software point of view. Some brief mention will be made of the hardware aspects, but the mathematical aspects of the SIL determination are not covered. For this, please refer to the publications listed in "8 References". It is intended to give some guidance on what the critical issues will be and to be precursor to engaging a specialist consultant to make a formal assessment of the potential work involved.

V1.0 Page | 3


1.1 Doing The Groundwork In an ideal world, the real motivator for applying IEC61508 should be improved product safety, not just extended product life. As might be expected, the elimination of potential failures through the design and development process plus the handling of any that do occur i.e. "safety", are all issues that must be addressed. It is important to realise that IEC61508 is not just about employing good software development measures like code reviews, MCDC, version control, MISRA checking etc. but also about the management of the development process from project concept to end-of-life. Therefore a documented development process that is at least compliant with ISO9000:2008 is essential as a starting point. Where there is an existing ISO9000 quality management system, typically it can take anything from 20-50 man days of effort to get up to the full IEC61508 functional safety process capability. To create the necessary level of documentation and implement the required testing for an existing project can be around £2 per line of code, as a very rough guide. If you have not got ISO9000 or TS16949, then it will be especially difficult to get a project full accredited certification under IEC61508. In many cases, the target SIL will be imposed from outside (key customers, marketing department requirements, competitors) otherwise the challenge of applying IEC61508 to an existing project would not arise in the first place. 1.2 Is the current hardware design capable of the required SIL? Unlike hardware, software does not have easily-defined ways of analysing failures, or determining FIT rates, to allow the SIL for the system to be derived. IEC61508 takes account of this by requiring different levels of engineering design process and implementation to ensure the reliability of the software in the system. Hardware though cannot be ignored and the actual SIL that the product is capable of is heavily influenced by the existing hardware design, so this must be examined first. For SIL2, a single CPU system may be suitable, but a Failure Mode And Effect Diagnostic Analysis (FMEDA) will be required to confirm this. If the existing product has some kind of external safety monitor (PIC16) or power regulator with a watchdog toggle pin, then it is likely that SIL2 is feasible from the hardware viewpoint. The important point is that there is some kind of independent check that the CPU is running correctly. Many properly-engineered industrial systems will already have this in some form. Awkward issues can arise with the general hardware design though. For example, if a fault detection mechanism uses one half of a dual opamp and the other half is used for the main controller that performs a potentially dangerous function, there is a potential "common cause" failure on the opamp which would render the fault detection mechanism useless. Thus it is vital to check the isolation of the safety-critical outputs and fault detection mechanisms. For SIL3, the situation is more complex. The external watchdog has to be something quite sophisticated, with the ability to verify the time behaviour and correct operation of the CPU instruction set. If this type of mechanism is not already incorporated into the hardware design, then it may well be unfeasible to continue and only SIL2 may be possible. The CPU may also need to have safety features like memory protection and error correction (ECC) on SRAM and FLASH, or be lock-stepped. As lockstep CPUs (e.g.

V1.0 Page | 4


Infineon Aurix, TI TMS570) are a recent innovation, it is unlikely that a mature hardware design will be based on these. In some cases, a later version of the existing CPU can offer relevant new features. For example, moving from the Infineon C167 or XC167 to XE167 will make memory protection and ECC available, or moving from TriCore to Aurix will give a lockstep core option. Other examples might be to upgrade from STM32F1 Cortex M3 to STM32F4 Cortex M4, or LPC1800 to LPC4000 to get memory protection. Moving between CPU families is not likely to make much sense for cost reasons and it would be better to start a completely new project from scratch. Realistically, SIL3 may well prove to be out of reach for most existing products unless some major additional engineering work is carried out. If it is decided to go for IEC61508 certification then the hardware and any diagnostics measures (hardware and software) will need to be formally analysed to work out the real FIT (Failure in Time) rate of the system, so the exact mix of fault diagnostics and CPU safety features needed can be finalised. The various SILs have different target FIT rates and the diagnostic mechanisms and CPU features (memory protection, lock-step etc.) all combine to give an overall FIT value. The approach used is the Failure Mode And Effect Diagnostic Analysis (FMEDA) which usually results in a large and complex spreadsheet. FMEDA builds on the familiar Failure Mode And Effects Analysis often used in hardware design and says "what are the FIT rates after we add some fault diagnostics". Therefore the overall FIT is the FIT of the component itself x (100-% of faults that the diagnostic can detect in that component)/100 where 1 FIT = 1 failure per 10E9 hours. Producing a FMEDA is a complex procedure and it not covered in this piece. 1.3 The Development Process From the target SIL, the measures and development processes required can derived. From the overall development process point of view there are some differences between SIL3 and SIL2. For example, the required continuous assessment of the management of the development process at key milestones for a SIL2 project can be performed by an independent person in the same department, while at SIL3 it must be somebody from a completely independent department. However, the main difference is in the implementation of the hardware and software. Therefore we will concentrate on the SIL3 process, as this represents the greatest challenge.

V1.0 Page | 5


2 The IEC61508 Safety Lifecycle The safety aspects of the development process are officially managed through the “Safety Lifecycle” and demonstrating adherence to this is a major part of any IEC61508 assessment. This lifecycle applies to the management of the project and the design and development of individual components within the system.

Safety Lifecycle adapted from IEC61508-1, Fig 2

Overall scope definition

Safety Functional & Safety Integrity Requirements

Safety requirements allocation to SW and

HW elements

Overall operation and maintenance

planning

Overall safety validation planning

Overall installation and commissioning

planning

Safety Related System

Realisation (HW & SW)

Overall installation and commissioning

Overall safety validation

Overall operation, maintenance & repair

Decommissioning or disposal

Overall modification and retrofit

Back to appropriate overall safety lifecycle

phase

Concept

V1.0 Page | 6


2.1 Safety Lifecycle Documents Documents will need to be prepared to cover each of these items. These are typically named “1234.00001 Master Test Plan.docx”, “1234.100001 Change Management Plan” and so on, where “1234” is the project number and “.XXXXX” is the individual and unique document number. A typical set of documents for the software elements might be: Document Description

1234.30000 Software Project Management Plan.docx High-level details of how project is to be executed and by whom. It also states the major project milestones.

1234.30009 External Risk Management.xlsx A list of risks that could prevent or delay completion of project, along with mitigating actions.

1234.30010 Documentation Plan.xlsm A list of all the documents that will need to be generated

1234.31000 Master Test Plan.docx Provides a central document to exercise control of the test effort. It defines the test strategy, the verification and validation activities and the supporting requirements that will be employed to test the system and to provide visibility to stakeholders that adequate consideration has been given to various aspects of testing.

1234.33000 Configuration Management plan.docx This document identifies specific configuration management issues, defines instructions for creating and maintaining a clean and clear repository, creates specific ways of working for configuration items, manages configuration items and states how version control will be managed.

1234.33001 Change Management Plan.docx States how change management is handled. It analyses and manages changes to safety-related work products generated during the safety lifecycle.

1234.34000 Quality Assurance Plan.docx Describes the standards, procedures and practices that are used as guidelines for the project. Contents of this document are applicable to the software development phases of this project.

V1.0 Page | 7


1234.36000 Safety Plan PROJECTNAME.docx Describes how the safety life cycle of the system is to be developed and executed and describes how the safety life cycle will be documented in the project. It identifies the interfaces between the parties involved who may be developing different parts of the safety life cycle. This document also describes the product safety life cycle for the project and correlates safety-related activities to the project plan. The purpose of this document is to identify the safety-related activities that have to be executed during the project, to determine when they have to be executed and to define how the safety-related activities shall be documented. Another purpose of the safety plan is to serve as a documentation reference point, which references a list mapping IEC61508 requirements to development activities and their respective documents.

1234.36001 Safety Case Report PROJECTNAME.docx Provides documentary evidence which supports the safety claim and provides references to all documents underpinning the claim.

1234.36003 IEC61508 Safety Checklist.docx A list of IEC61508 requirements which must be reviewed for compliance at each milestone stated in the Project Management Plan. Failure to meet an IEC61508 requirement will prevent the milestone being passed.

By ensuring that there is a planning document for each item shown in the safety lifecycle diagram, most of the auditable safety-related issues will be covered. That is not to trivialise the task of creating these documents, especially the Safety Management Plan and Master Test Plan.

V1.0 Page | 8


3 Undertaking the IEC61508 Conversion 3.1 IEC61508 Gap Analysis For an existing project, any existing planning documentation and specifications need to be collected together and reviewed, to allow the completeness of the existing project to be seen. They are very unlikely to meet the requirements of IEC61508 as they stand, so a gap analysis must be performed. In the event of going for IEC61508 certification, the assessor will really only check that the process has been followed, that requirements can be traced to specific tests and that specific tests can be traced back to requirements (not always so easy). This can only be done on the basis of the documentation presented, so it is vital to make sure that it is complete. 3.2 V-Development Model IEC61508 requires the use of the V-model of system development. Here, for every requirement (phase V3), there should be a matching test on the other side of the ‘V’ in SW testing (phase V9). All the planning phases are down the left hand side with matching testing phases on the right hand side. The actual writing of the source code sits at the base of the 'V'. In practice, some phases occur iteratively. For example, V5, V6, V7 and V8 tend to repeat, as problems during testing are found and corrected. Phases V3 and V4 can also repeat as the requirements become better defined, usually in the light of experience gained further down the process.

Software Project Scope

V1

V5

system requirementsdevelopment

V2

system architecturaldesign

V3

SW requirementsdevelopment

V4

SW architecturedevelopment

SW detailed design SW unit testing

SW implementation

SWintegration

SWtesting

system integrationtesting

system testing

V6

V7

V8

V9

V10

V11

V1.0 Page | 9


You will need to map the existing project documents onto the V-model to find the missing items, even if it was never formally managed that way. 3.3 Requirements Commonly the overall requirements specification will have been written at the start of the project but not then kept up to date. If there are no specifications at all and the functionality is only described by the code itself, you should really ask yourself whether this type of project can actually be salvaged and submitted for assessment. The cost of getting it compliant may be more than starting the whole thing again. Requirements traceability is one of the most important aspects to IEC61508. It must be possible to show that all requirements (especially safety-related) have been met through specific tests. Existing projects should at least have tests in place for the operation of safety-related functions, albeit in a poorly documented form. In reality, the requirements must be derived from whatever documents exist and even from the code itself. Often problems are discovered at this stage – missing requirements i.e. code exists but with no associated requirement, or with a requirement that has no test to prove it has been met. The result should be a matrix which shows the requirements and any relevant tests. For IEC61508, the overall requirements will be of three basic types: 1. Safety functional requirements These relate to the input to output transfer function that controls a safety-critical device e.g. a gas-fired boiler could have a steam pressure sensor (input) that can reach a maximum value (algorithm) before the gas is shut off (output) to the burner. Each requirement is allocated a SIL which is then combined with all other elements to get the overall SIL. However, where the SIL is externally imposed, the SIL of each element must be >= to the target SIL. 2. Safety integrity requirements These consist of separate diagnostic mechanisms, or fail-safes, that detect that the safety-critical system has failed and force the outputs into a safe state. E.g. Examples of integrity elements in the boiler would be a current-range diagnostic on the pressure sensor, or a watchdog timer. If either of these elements detected a failure they would be able to force the system to a safe state. 3. Non-safety requirements These are related to functions that cannot cause a safety hazard. E.g. SD card driver in data logger. IEC61508 has the concept of “Criticality Analysis” which helps to determine the SIL needed for each element, whether they be safety functional, safety integrity or non-safety requirements. The SIL then determines the level of testing required. The method for this analysis can be used for software components and the system as a whole.

V1.0 Page | 10


Each module is classified into one of four criticality levels:

• C3—Safety Critical: a module where a single failure or error could cause the system to fail dangerously. This is a single point fault

• C2—Safety Related: a module where a single failure or error cannot cause the system to fail dangerously, but in combination with the failure of a second module could cause a dangerous fault. This is effectively a dual point fault and is usually used for any diagnostic/error detection subsystems.

• C1—Freedom from Interference: a function that is not safety critical or safety related, but has interfaces with such modules i.e. runs on the same CPU.

• C0—Not Safety Related: a module that has no interfaces to safety related or safety critical modules. At the simplest level, any module that is directly used in implementing a safety requirement would be C3 and any safety integrity requirements would be C2. In a SIL3 system, the diagnostics subsystem would only need to be SIL2. For a SIL2 system, the diagnostics would only need to be SIL1. In practice this means that software concerned with diagnostics does not require such rigorous testing. IEC61508 also has the concept of "low" and "high demand" systems. In general, high demand systems are those where a failure is likely to cause a hazard on a continuous basis. For example, a motor driving a conveyor failing to stop could result in a hazard. As the potential for a failure to stop is always present, such a system is termed "high demand". Low demand systems are those that are only called upon to operate when the main equipment under control fails and are usually add-on safety mechanisms. In the conveyor example, an automatic safety brake would be a low demand system. If you can partition your system into blocks that implement safety related and non safety related requirements, then you may be able to claim that some functions are not critical and leave them out completely (Criticality = C1). For example, code that logs data to a SD card is probably not safety related so any functions associated with it can be excluded from the safety system. However as the SD card driver runs on the same CPU, this would mean you would need to prove “freedom from interference” between the safety related code and data and non safety related code, using some kind of hardware memory protection system, or some other mechanism such as encapsulation of objects in C++. 3.4 Testing Based on the requirements derived, the tests can be planned. No huge detail is required and some tests can just be placeholders. Of course, when constructing the master test plan for an existing project, most of the tests that will be needed should already be known and just need documenting. Find the details of any tests which were envisaged or planned before the development started (these are what you really should have) and those that were added once the first boards arrived. These should then be matched up with the known requirements. Where there is a requirement with no test, a placeholder needs to be created pending the development of a suitable test. Any test will be need to be assigned some kind of identifier e.g. STS_001, STS_002 (STS => Software Test Specification).

V1.0 Page | 11


Unit tests are a separate issue and generally every safety related function will need a unit test. Lack of full unit testing is very common, but it is a fundamental requirement for quality and IEC61508. If the individual functions are wrong, then there is no hope that the whole system will be correct. Properly conducted projects will have some unit tests, but often they are not updated when changes are made. They will probably need to be assigned identifiers such as UTS_GasModulator_001, UTS_GasModulator_002 and so on, to allow them to be associated with a particular function, a particular software process and finally the original software requirement. Whether the tests were performed using a PC compiler and executed on a PC, or performed on the final target via a debugger and with the cross compiler needs to be ascertained. Unit testing of embedded code on a PC is common, but this is not really acceptable for IEC61508, especially at SIL3. Whether the unit tests are easy to re-run as regression tests needs also to be checked. Unit tests that are implemented in a dedicated unit test tool like TESSY can automatically become regression tests and can be re-run easily. Those that are based on test harnesses tend to be very hard to repeat and you should give some serious consideration to obtaining an automated unit test tool if you decide to go for IEC61508 accreditation. Integration tests are useful, but tend to be very poorly recorded and very hard to repeat. They will be needed though, to show that the various software blocks can co-exist without unwanted interactions (i.e. freedom from interference). Testing of safety mechanisms is especially important and if such tests do not already exist, they must be defined and implemented. This testing sits at the highest level under System (or Software) Validation and must completely test each safety function and safety integrity requirement. The validation should take place in as representative an environment as possible. Fault injection must be used and can come in the form of communications faults, input loading, power and environmental faults. 3.5 Allocating The Requirements To Software And Hardware Once all the requirement have been collected together, allocate the safety functional, safety integrity requirements and non-safety requirements to specific hardware or software components. Sometimes simple HW-based safety integrity measures like a resistor network and a comparator are used to switch off an output when an input voltage goes out of range, so what looks like a software requirement in fact is a hardware requirement. On the pure software side, if the modules that carry out safety related tasks can be isolated from the safety integrity and non-safety functions, then it will considerably reduce the development and testing effort. It should be noted that for both SW and HW, any safety integrity measure must only be able to disable a safety related output. Clearly if they could enable a safety critical output that is supposed to be in an off (safe) state, then an unintentional hazard would be created. However, freedom from interference between safety functional, safety integrity and non-safety functions must be demonstrable, which could require measures such as dual processors, or memory protection, or dual and redundant algorithms with time separation and an independent and external compare mechanism (e.g. CIC61508 safety monitor). For an existing design the latter is likely to be the most practicable, provided that there is some spare CPU capacity. This is covered in more detail later.

V1.0 Page | 12


3.6 Implementing The Documentation During any assessment exercise, a sample of project documentation will be examined to make sure it complies with IEC61508 requirements. On a project of any real size, it is almost impossible to examine every document and every C function, mainly for cost reasons. At SIL3 the sampling will be more extensive than at SIL2. The assessor will have a checklist based on IEC61508-3, chapter 7 and will verify that for the target SIL, there is evidence that the right steps have been taken. For example, at all SILs, “Use of structured methods”, “Clear partitioning into functions” etc. will be looked for. At SIL2 items such as “Clear visibility of logic used”, “No dynamic objects” will be checked for. SIL3 requires evidence of “Limited pointers, interrupts, recursion”. The assessor can only verify these items from the documentation presented, so it is important to make sure it is thorough. There needs to be a document mapping the development process used to the IEC61508 requirements. The document templates, forms, standard test procedures that already exist in the company need to be associated with the requirements of IEC61508 in some kind of matrix. This may well happen as part of the gap analysis. Any missing documents will need to be created, based on the standard. The most important of these documents are covered in the following: 3.7 Reviews Peer review is an essential feature of the IEC61508 development process, as it is with ISO9001. It works on the four-eyes-are-better-than-one principle where all documents, source files etc. are reviewed before being released. Reviewing complex documents or source modules that were created by others is not easy to do well and some significant time must be taken over it. Often the original author will find problems simply by re-examining items, which is in itself useful. Documents forming part of any existing project must extensively reviewed before they can be added to an IEC61508 project anyway. Documents will pass through the following stages: Draft: Gathering of information to form a new document or revision of a document. Review: At least one person other than the author will review the document. Authorising: All the comments received from all reviewers are collected together into a Review Report and assessed by the author and optionally also by the participants in the review. It will be agreed which comments will be accepted or rejected.

Draft Internal Review Authorising Released

V1.0 Page | 13


The document that was subject to the review is then modified and up-issued and its status changed to Authorising. The new document is then circulated, along with the final Review Report, to the reviewers who must then verify that the comments have been actioned correctly. The document is up-issued again and moves to the Released state. Released: The document can be used within a project. At SIL3, a review of the review outcomes is also recommended. Here, the number of review issues raised by the reviewers is logged, along with the number of accepted and rejected changes. If reviews consistently generate too few issues, or too many, this could indicate that in one case the reviewers are not being thorough enough, or in the other case, the items being submitted for review are of inadequate quality. Under the SIL3 process, both matters need to be recorded and addressed. The software project documentation for IEC61508 has a distinct hierarchy, mainly driven by the need to get traceability from the software requirements to the unit, integration and software tests. Software Requirements Specification (SRS) Architectural Design Specification (ADS) Detailed Design Specifications (generally one per software process) (DDS) Unit Test Specifications (generally one per software process) (UTS) Integration Test Specification (ITS) Software Test Specification (STS) The traceability from requirements to test flows through these documents (see 6 Traceability).

V1.0 Page | 14


3.8 Software Requirement Specification (SRS) The root document is the Software Requirement Specification (SRS). This states the requirements which are allocated to the software alone. It will give a brief description of the reasoning behind each requirement and taken along with the Software Architectural Design Specification, it serves as input to the software detailed design and ultimately the software itself. Each requirement should be allocated an identifier, such as “SRS_xxxx” and be listed along with a short description including where the requirement came from. Typical requirement providers are change requests, product requirement definitions, previous known good practice, customer requests. Any special issues or related requirements should be noted and the SIL given to indicate the level of testing that will be required to demonstrate that the requirement has been met. All requirements must be reviewed and approved and this is recorded. The first software release name (taken from the configuration management plan) that addresses this requirement should also be given. The System Safety Requirements document may not be relevant for a software project but it will contain a hazard analysis (see [IEC] part 3) and risk reduction section, from which system safety requirements are defined. The Software Safety Requirements document defines both the generic requirements as defined by the [IEC] and the project-specific software safety requirements. In most respects, this document is very similar in

V1.0 Page | 15


layout and function to the Software Requirement Specification, which covers the basic function of the software but without particular reference to safety matters. 3.9 Architectural Design Specification (ADS) The Architectural Design Specification (ADS) is a high-level view of how the software will be structured. All modules to be implemented will be designed in detail. It describes the decomposition of the whole software system and shows how the software requirements are allocated to individual software processes. When appropriate, the interactions between software processes are also given. There needs to be some evidence of a structured design method (IEC61508-3: 7.4), so the ADS will need to show the system decomposed into major software units and the data flows between those units shown in data flow diagrams. The time relationship of modules also needs to be shown in sequence diagrams. Each software process is allocated a number e.g. the SPI driver is software process 10.

A SIL3 top level software architecture presented as a data flow diagram/control flow diagram.

For traceability purposes, the ADS should contain a matrix which shows which software process relates to which software requirement from the SRS.

ApplicationApplication

0505SilSil

0101SflSfl

0707TskMTskM

0606DcmpDcmp

0404TexMTexM

0202CicHCicH

0909 ApplCbkApplCbk

SflSfl__StartupHookStartupHook SflSfl

__ShutdownHookShutdownHook

TestIdTestId,Sample,Result,Sample,Result

TaskIdTaskIdSflSfl

__CheckXXXCheckXXX

SflSfl__CheckXXXCheckXXX

TexMTexM__ReportResultReportResult

TestIdTestId,Result,Result

ApplCbkApplCbk__CheckXXXCheckXXX

ApplCbkApplCbk__ErrorHandlerErrorHandler

CicHCicH__SetSfrSetSfr

Id, DataId, DataId, DataId, Data


0303OpcOpc

ResultResult

TestIdTestId

OpcOpc__StartOpcodeCheckStartOpcodeCheck

0808CICCIC_If_If

CICCIC_If_Read_If_Read

1010SpiSpi

DataDataDataData

SilSil__WriteStartErrorWriteStartError

ErrorError

ModeMode

SilSil__ReadModeReadMode

SpiSpi_Write_Write

SpiSpi_Read_Read

CicServiceCicService

<<<< SfrSfr __ C

allBackC

allBack >>>>

OpcOpc__RunOpcodeCheckRunOpcodeCheck

TestIdTestId

ResultResult

TexMTexM__ReportResultReportResult

CicHCicH_Get/_Get/SetCicServiceSetCicService

TestIdTestId,Result,Result

DcmpDcmp_Report<_Report<DataTypeDataType>Result>Result

TskMTskM__ActivateTaskActivateTask

TskMTskM__TerminateTaskTerminateTask

Id, DataId, DataCicHCicH

__GetSfrGetSfr


Id,Id, CallBackCallBack

CICCIC_If_Write_If_Write

Id, DataId, Data

Id,Id, CallBackCallBack

Id,Data

Id,Data

ErrorIdErrorId,, TestIdTestId

SflSfl__CheckDataXXXCheckDataXXX

OpcOpc__GetOpcodeCheckResultGetOpcodeCheckResult

OpcOpc__ManageOpcodeSequenceTestManageOpcodeSequenceTest

(optional)(optional)

V1.0 Page | 16


3.10 Detailed Design Specifications (DDS) The Detailed Design Specifications (DDS) need to show the control flow and the data flows again and allocate a process relation number to each function that allows a traceability link to be made back to the ADS. For example, a SPI driver has been given the process number of 10. The constituent functions of the driver are then numbered 10.1, 10.2, 10.3 etc. to show that that they are components in the software process 10. The functions that are called from external software processes (the “interfaces”) are listed separately, with tables showing the software requirement that it relates to, along with details of the input parameters and return value. The traceability from the ADS and SRS passes through these interface functions, which is why they are separated out from the functions which are purely internal to the software process.

Name Spi_RxTxHandler Control Process NotAControlProcess Identifier 10.2B Development Status

New Safety Related

Yes

Verification Status False SIL NA Process Description This process contains the task body of the SPI handler communication. It is running as an interrupt and will handle the reception and transmission of datawords. Requirements Provider

SRS_596, SRS_617, SRS_737

Verification conditions

TxDataTxData RxDataRxDataSpi_WriteSpi_Write Spi_ReadSpi_Read

Spi_InitSpi_Init

10.110.1Spi_InitSpi_Init

10.2A10.2ASpi_RxTxSpi_RxTx

10.2B10.2BSpi_RxTxHandlerSpi_RxTxHandler

10.310.3Spi_ReadSpi_Read

10.410.4Spi_WriteSpi_Write

Spi_WriteBufferSpi_WriteBuffer Spi_ReadBufferSpi_ReadBuffer

TxDataTxData

TxDataTxData RxDataRxData

RxDataRxData

GPIOSettingsGPIOSettings

TxBufInitDataTxBufInitData

RxBufInitDataRxBufInitData

USICSettingsUSICSettings

TexM_ReportResultTexM_ReportResult

Spi_ReportBufferSpi_ReportBuffer

TestResultTestResult

TestResultTestResult TestResultTestResult

Spi_RxTxSpi_RxTx

RrBufInitDataRrBufInitData

TxDataTxData RxDataRxData

TestId, ResultTestId, ResultTexM_ReportResultTexM_ReportResult

TestId, ResultTestId, Result

USIC registersUSIC registers GPI / GPO registersGPI / GPO registers

V1.0 Page | 17


n/a

Inputs Spi_RxTx RxFIFO buffer limit reached interrupt trigger RxData Received register data from SPI channel TxData Buffered data to be written to SPI channel Outputs TxData Data to be written to SPI channel registers

RxData Received data from SPI channel that will be buffered

TestResult Test result data that will be buffered A detailed description of the operation of each function is made, with any unusual or CPU-specific practices or measures highlighted. A flow chart is normally used to indicate the operation of the function. If an existing project is being used as an input to the IEC61508_based project, then the flowchart can be created from the original source code using a tool like Visustin or DA-C. However, this is the only situation where this form of “reverse engineering” is acceptable. Finally, for traceability a matrix is needed relating the process relation numbers for each function (10.1, 10.2 etc) to the software requirements, along with a table showing how the individual functions are related to the process relation numbers. 10.1 10.2A 10.B 10.3 10.4 SRS_596 X X X X X SRS_617 X X X X X SRS_737 X X X X X Software requirements vs. processes traceability

10.1 10.2A 10.2B 10.3 10.4 Spi_Init X Spi_RxTx X Spi_RxTxHandler X Spi_Read X Spi_Write X Processes vs. routine traceability

V1.0 Page | 18


3.11 Unit Test Specifications The UTS need to define all the unit tests for each function. Every path through a particular function needs to be identified and given an identifier e.g. UTS_SPI_001, UTS_SPIr_002 and so on. These paths need to be based on the branches within the function.

Flowchart annotated with branch indexes

Path Id Route Description UTS_SPI_220 1-2-3-4-5-6-10 Normal flow of Spi_Read UTS_SPI_221 1-8-10 Report value is corrupted UTS_SPI_222 1-2-7-4-9-10 Error reported when report value is not equal to SCII_OK, and

ReceiveBuffer is empty UTS_SPI_223 1-2-3-8-10 RxCount value is corrupted UTS_SPI_224 1-2-3-4-5-8-10 RxTail value is corrupted

Path Analysis Example

EndEnd

Result ==Result == SCIISCII_OK_OK

TRUETRUE

TxCountTxCount < <SPISPI_TX__TX_BUFBUF_SIZE_SIZE

Result=Spi_GetWriteBufferHead(&TxHead)Result=Spi_GetWriteBufferHead(&TxHead)

Result=Spi_GetWriteBufferCount(&TxCount)Result=Spi_GetWriteBufferCount(&TxCount)


TRUETRUE

TexM_ReportResult(SCII_SPI_ID,TexM_ReportResult(SCII_SPI_ID,SCII_E_ACCESSSCII_E_ACCESS

SpiSpi__WriteBufferWriteBuffer[[TxHeadTxHead] =] = TxDataTxData

TxHeadTxHead++++TxHeadTxHead &= &= SPISPI_TX__TX_BUFBUF_MASK_MASK

TxCountTxCount++++

Spi_SetWriteBufferHead(TxHead)Spi_SetWriteBufferHead(TxHead)

TRUETRUE

StartStart

FALSEFALSE

FALSEFALSE

Spi_SetWriteBufferCount(TxCount)Spi_SetWriteBufferCount(TxCount)

TexM_ReportResult(SCII_SPI_ID,TexM_ReportResult(SCII_SPI_ID,SCII_E_COMMSCII_E_COMM

FALSEFALSE

RetvalRetval = = SCIISCII_E_ACCESS_E_ACCESSRetValRetVal = = SCIISCII_E_COMM_E_COMM

Result=Spi_GetReportBuffer(&Report)Result=Spi_GetReportBuffer(&Report)

TRUETRUE

TexM_ReportResult(SCII_SPI_ID,Report)TexM_ReportResult(SCII_SPI_ID,Report)FALSEFALSE


FALSEFALSE

TRUETRUE

Report ==Report == SCIISCII_OK_OK

RetValRetVal = = SCIISCII_OK_OK

11

22

33

44

55

66

77

88

99

HWTxHWTx FIFO FIFOempty?empty?

RequestRequest TxRxTxRx interrupt interrupt

TRUETRUE

FALSEFALSE 1010

Enter critical sectionEnter critical section

Exit critical sectionExit critical section

1111

V1.0 Page | 19


From the path analysis, testcases are generated which state the initial conditions, parameters passed and the expected result. The latter can be either a return value (preferred method) or a global variable. Each testcase is assigned an identifier of the form SPI_<functionname>_001, SPI_<functionname>_002 and so on. Test Case Id SPI_Read_001 Safety Related Yes Dynamic Test Functional Test technique

Control flow testing

Description This test case will cover the Normal flow of Spi_Read. The RxTail overflow will be tested too.

Pre-condition All Get results are SCII_OK Report = SCII_OK RxCount = 1 RxTail = SPI_RX_BUF_SIZE-1

Test Path UTS_SPI_220 Expected test result

RxCount = 0 RxTail = 0 RxData = Spi_ReadBuffer[RxTail]

A single testcase definition

By identifying all the different paths, it can be shown that all statements and branches were executed (100% code coverage). If the expected result is always obtained, then it is reasonable to assume that the function is bug free. However, how the code coverage is obtained is related to the target SIL. For SIL2, 100% branch coverage is usually sufficient. Here both sides of any conditional branch are exercised. However, for SIL3 every condition in a compound conditional branch (e.g. &&, ||) must be exercised. This derives from aerospace standard DO178B and is known as Modified Condition Decision Coverage (MCDC). At one time, it used to require considerable additional testing effort to achieve 100% MCDC but with automated unit test tools like TESSY, the implementation effort for MCDC is not much more than simple branch coverage, so even at SIL2 it is worth using. To get 100% MCDC, the input test data is chosen from boundary value analysis, equivalence classes, input partitioning, error seeding (or mutation), or error guessing. IEC61508-7, C5 contains more information on this subject. Traceability is recorded in tables of Test Path ID vs. Test case ID and Interface vs Test path. Test Case Id Test Path SPI_Init_001

UTS_SPI_170

SPI_RXTX_001

UTS_SPI_155, UTS_SPI_214

V1.0 Page | 20


SPI_RXTX_002


SPI_RXTX_003


SPI_RXTX_004


SPI_RXTX_005


SPI_RXTX_006


SPI_RXTX_007


(truncated)….

Spi_Init

Spi_RxTxHanlder

Spi_Read

Spi_Write

Spi_SetReportBuffer

Spi_GetReportBuffer

Spi_RxTx

UTS_SPI_170 X UTS_SPI_155 X UTS_SPI_158 X UTS_SPI_210 X UTS_SPI_211 X UTS_SPI_212 X UTS_SPI_213 X UTS_SPI_214 X UTS_SPI_215 X UTS_SPI_220 X UTS_SPI_221 X UTS_SPI_222 X UTS_SPI_223 X (truncated)….

V1.0 Page | 21


3.12 Integration Test Specifications (ITS) The ITS needs to show that the major software functional blocks defined in the ADS work correctly, both in isolation and together. Where SW is being developed from scratch under IEC61508, the integration tests will be built up from groups of functions, with each test given an identifier e.g. ITS_GasModulator_001. Functions from external software blocks are likely to be stubbed out. These groups will then be combined and subjected to further tests, until a complete software subsystem has been assembled. At each stage, an identifier will be given to the overall sub-system under test. Integration tests are often performed using test harnesses custom-written for the job, but some unit test tools can also be used this way. It is important that integration tests can be easily repeated, in case changes are made later in the project. The way that the unit tests and integration tests will be performed is defined in the Master Test Plan. For example, it is important to make sure that the execution environment for any unit and integration tests is as close to the final program’s running conditions as possible. It used to be quite common for embedded C coded functions and their hand-crafted test harness instrumented with a third-party tool then to be cross-compiled with Microsoft C. The execution was on a PC. This approach proves the correctness of the C code, but takes no account of any differences between the PC compiler and the embedded cross-compiler, of which there inevitably will be some. For example, differing sizes of the “int” type and pointer behaviour. The result could be that unit tests pass on the PC which in fact will fail on the embedded target. For 16 and 8-bit microcontrollers, this approach is not really acceptable for SIL3 and is questionable for SIL2. For 32-bit microcontrollers, the risks are reduced by the same basic word size as a PC but even then, its merit is still debatable. Thus whenever possible, tests should be run on the final target CPU using the final cross-compiler. 3.13 Software Validation Testing (STS) This generally involves running the complete system under normal and abnormal conditions and checking that the safety mechanisms are functional. It should also involve tests that are derived from real world experience, not just tests derived from the original requirements. The tests will most likely be performed on the real hardware and so to some extent may act as part of the overall system validation test. The main objective of these tests is to prove that all requirements have been met. For an existing project, these tests are likely to exist and be reasonably well documented. One point that is often overlooked is that any functional problems found during unit or integration testing must be subjected to an impact analysis, to see what effect fixing the local problem will have and then using the normal change request procedure to trigger the actual change. Quick fixes are therefore not possible! At SIL3, any change at all will require a full system validation re-test, whereas at SIL2 and below, only the affected modules (i.e. all directly related functions) must be retested. Being able to re-run unit tests and integration tests easily is important in these situations.

V1.0 Page | 22


3.14 Code Reviews Source code must be reviewed for all SILs before being released. It is sensible to make sure that that the code has already been tested for coding guideline problems before submitting it for review. Commonly this means using a static analysis tool such as PC-Lint with an appropriate .lnt file, or something more sophisticated like DA-C or Understand. Code review is not an easy job and experience has shown that the originator of the source code will find the most issues. For embedded projects, it helps to have a review team consisting of one CPU architecture expert, someone well versed in coding standards (e.g. MISRA) and style guides and someone else who has previous experience of implementing similar functionality in earlier projects. A team member who understands the unit testing process is also useful, as testability is an important issue. A standard review form is essential, to make sure that all reviews are conducted and recorded in the same way. If the code under examination is changed as a result of the review, any associated unit tests and detailed design specifications must also be reviewed to verify that they are still appropriate. If not, they must also be changed and re-released. Where existing code or a complete project is being prepared for IEC61508, all code should be reviewed as a matter of course. If the existing code has not been written using a coding standard or style guide, then applying these retrospectively is a major but essential task. //--------------------------------------------------------------------------- // Modification required for the Tasking VX-toolset compiler for C166 v3.0r3 //--------------------------------------------------------------------------- +rw(_to_brackets) // activate the _to_brackets keyword // causes reserved word and trailing '[' ']' to be ignored +rw(_gobble) // activate the _gobble keyword // causes _gobble token to be both ignored -"esym(950,_to_brackets, _gobble)" //ignore these Non-ISO/ANSI reserved word or construct -d__interrupt=_to_brackets // enable the (non-standard) __interrupt() keyword -d__at=_to_brackets // enable the (non-standard) __at() keyword -d__asm=_to_brackets // enable the (non-standard) __asm() keyword -dinline=/* */ // enable the (non-standard) inline keyword -d__iram=/* */ // enable the (non-standard) __iram keyword -d__registerbank=_to_brackets // enable the (non-standard) __registerbank() keyword -d__frame=_to_brackets +fie // enums are of type int in SC-II Extract of .lnt file for Tasking VX C166 language extensions used in a SIL3 project

Usually most issues can be fixed easily, but in deeply embedded code some necessary programming practices will generate coding standard exceptions that cannot be eliminated. These exceptions are usually related to pointers and absolute addresses. They should be documented on a per module basis in the Safety Case Report, along with a justification for their use. MISRA RULE 11.4 VIOLATION: 929: Violates MISRA 2004 Required Rule 11.4,

V1.0 Page | 23


Cast from pointer to pointer This exclusion has been added as this is necessary for the operation of the system. Checks have been made that this does not result in a hazard (huge pointers). MISRA RULE 9.1 VIOLATION: 530 & 727: Violates MISRA 2004 Required Rule 9.1, Symbol 'R0image_Cached' not initialized. Symbol 'R1image_Cached' not initialized. The following exclusion was added as the preceding function's return values are made via these global variables. MISRA RULE 11.3 VIOLATION: The following exclusion was added because this rule is advisory and it is unavoidable when addressing memory mapped registers or hardware specific locations.

An example of a MISRA C2: 2004 exception summary might be:

MISRA Rule Instances MISRA RULE 1.1 6 MISRA RULE 1.2 1 MISRA RULE 11.3 40 MISRA RULE 11.4 1 MISRA RULE 12.4 10 MISRA RULE 12.6 2 MISRA RULE 17.4 40 MISRA RULE 19.6 1 MISRA RULE 2.1 9 MISRA RULE 6.3 2 MISRA RULE 8.10 13 MISRA RULE 9.1 8 Total Violations 133

MISRA C2: 2004 exception metrics

V1.0 Page | 24


3.15 Product/Software Metrics At SIL2 and SIL3, the code must be subjected to static analysis to derive information on its complexity, call nesting, comment density etc. A typical set of metrics might be: Comment density Number of levels Number of paths Number of returns Number of GOTO’s Stability of code Cyclomatic complexity per function Vocabulary complexity Calling functions HIS MISRA scope violations Functions called HIS MISRA scope violations per rule Parameters per function Call graph recursions Statements per function

Deriving this kind of information requires the use of a tool such as DA-C or Understand, as it is almost impossible to do manually. Metric nr. Metric name Targe

t lower bound

Target upper bound

Percentage functions Out Of Bounds

Percentage functions in bounds

M25 Comment density 0,2 4,48% 95,52% M26 Number of paths 1 80 0,50% 99,50% M27 Number of GOTO’s 0 0 0% 100,00% M28 Cyclomatic complexity per function 1 10 1,99% 98,01% M29 Calling functions 0 5 1,99% 98,01% M30 Functions called 0 7 4,48% 95,52% M31 Parameters per function 0 5 0% 100,00% M32 Statements per function 1 50 0,50% 99,50% M33 Number of levels 0 4 8,46% 91,54% M34 Number of returns 0 1 0% 100,00% M35 Stability of code 0 1 100,00% M36 Vocabulary complexity 1 4 4,48% 95,52% M37 MISRA scope violations 0 0 M38 MISRA scope violations per rule 0 0 See Error!

Reference source not found.

100,00%

Typical metrics results

Finally development process metrics are listed. This is an area which any existing project that is being considered for IEC61508 accreditation is unlikely to address. As IEC61508 expects adherence to a well-defined development process, it is not surprising that it demands information on the performance of the

V1.0 Page | 25


process. It summarizes the number of outstanding change requests (CR), problem reports (PR), the effort per software requirement, as shown below: Example process metrics summary

Metric nr.

Metric name Target Release v2.3

Target Release v2.4

Realized Release v2.3

Realized Release v2.4

Comment

M01 Effort Within calculated effort

Within calculated effort

Confidential

M02 Progress 95% 100% Confidential M03 Budget Within

calculated budget

Within calculated budget

Confidential

M04.1 New CR’s 0% 0% 0% 0% From Track+ M04.2 Analysed CR’s 0% 0% 0% 0% From Track+ M04.3 Assigned CR’s 0% 0% 0% 0% From Track+ M04.4 Fixed CR’s 0% 0% 0% 0% From Track+ M04.5 Open CR’s 0% 0% 5% 0% M04.6 Verified CR’s 0% 0% 0% 0% From Track+ M04.7 Closed CR’s 100% 100% 95% 100% From Track+ M04.8 Rejected CR’s 0% 0% 0% 0% From Track+ M04.9 Postponed CR’s 0% 0% 0% 0% From Track+ M05.1 New PR’s 0% 0% 7,5% 0% From Track+ M05.2 Analysed PR’s 0% 0% 0,5% 0% From Track+ M05.3 Assigned PR’s 0% 0% 17,0% 0% From Track+ M05.4 Fixed PR’s 0% 0% 0% 0% From Track+ M05.5 Open PR’s 0% 0% 10,0% 0% From Track+ M05.6 Verified PR’s 0% 0% 0% 0% From Track+ M05.7 Closed PR’s 100% 100% 82,0% 100% From Track+ M05.8 Rejected PR’s 0% 0% 0% 0% From Track+ M05.9 Postponed PR’s 0% 0% 0% 0% From Track+ M07 First time stable

requirements 100% 100% 96% 99% 3/1/2013 147 in v2.4

M08 First time ready requirements

100% 100% 0% 100%

M09 Overall efficiency of requirements

No target No target 2 1

M10 Specific cost of requirements

No target No target 0,75 h/req

0,75 h/req

M13 Fault Detection No target No target v0.1: A=48 v1.1: A=12

M14 Fault Removal No target No target A=9 A=2 M16 Completeness of

description 100% 100% -

V1.0 Page | 26


4 Tool qualification Development tools used to create software for IEC61508-certified applications have also to be considered against the requirements of the standard. This includes compiler and unit/integration test tools. For example, IEC61508 61508 states that a tool such as a C compiler should preferably be “certified”, although it does not formally define what “certified” means. In addition, it states that the tool should be validated against its own specification or documentation. Compilers and their run-time libraries have a major role in creating safety-critical parts of the application which makes them implicitly safety-related. This then implies that they need a SIL that is not less than one below the SIL of the system itself. The foregoing also applies to middleware, but real time operating systems are particularly crucial. Worst case, this means that you would have to test all used tools fully in your own project unless appropriate evidence of testing can be provided Tool vendors can help by taking one of two approaches to establish their product's suitability for safety applications: (i) Have the product itself certified to SIL3 to cover 99% of all potential customer applications. This is the ideal route because it clearly establishes to what level the software can be used and simplifies the compliance argument for the end user when submitting the system for assessment. This usually means that the compiler version is fixed and only that release is covered by the certification and thus may be used in safety applications. This route is relatively commonplace for testing tools but unusual for compilers. (ii) The alternative is that the tool’s suitability for safety use is based on the “proof in use” or “increased confidence from use” principle allowed by IEC61508. A report is prepared for the chosen compiler release that demonstrates that the tool is "proven in use" by showing that it has been used in different products by a large user base over an extended period and that the defects reported during that time have been recorded and published. The types of applications used as a reference must either be very similar to the proposed application, or have been used in a diverse set of applications, thereby establishing broad test coverage. The report must also state the behaviour of the compiler-generated executable in the implementation-specific areas of the ISO-C standard e.g. pointer behaviour, type sizes etc. The influence of specific compiler (and linker) controls must also be recorded based on dynamic tests using an unit test-like approach. The run-time libraries must also be tested to determine their behaviour, but the scope of this has to be limited by specifying a reduced set of compiler controls. The tool development process employed must also be described, along with the results of any standard compiler test suites like Plum-Hall. All or one of these approaches have been taken by embedded compiler vendors such as Tasking (Tricore), Keil/ARM (ARM/Cortex/C166) and IAR (ARM/Cortex). Either the report or accreditation certificate is submitted for assessment. Real time operating systems often perform the most important role in a safety-critical system. Process and stack management, scheduling and flow control, and memory protection all have an impact on the safety

V1.0 Page | 27


function and can be key elements of meeting safety-integrity requirements. Where the operating system is not certified, it may be possible to locate the safety-related functions outside the operating system and run them directly from interrupts - some kind of hardware memory protection would also be desirable. However, some operating systems such as SafeRTOS can be had with a pre-certification pack from TUEV-SUED. Unit testing tools such as TESSY also have a tool qualification pack. TESSY Module Testing Tool Qualification Certificate

To a lesser extent, you must also consider how other tools you use in software development can affect safety, such as make and build tools, version-control software, and debuggers. However these only need to be documented with their respective version numbers in the Safety Case.

V1.0 Page | 28


5 Safety Documentation There are two safety-related documents required - the Safety Plan and the Safety Case Report. These are covered below. 5.1 The Safety Plan Perhaps the most important document after the Software Requirements Specification is the Project Safety Plan. This document describes the product safety life cycle for the project and correlates safety related activities to the project plan. Its purpose is to identify the safety related activities that have to be executed during the project, to determine when they have to be executed and to define how the safety related activities are to be documented. Finally it serves as a mapping of IEC61508 requirements to project activities and their respective documents. In brief, it contains information on:

• Roles and responsibilities of the staff • Defines the safety management team with safety-specific roles and responsibilities • Defines the safety life cycle

Safety functions requirementsspecification

Safety integrity requirementsspecification

Software safety requirements specification

Software safety validationplanning

Software design anddevelopment

PE integration(hardware/software)

Software operation andmodification procedures

Software safetyvalidation

• Defines at a top level the development process, and the V-development model as applied on this

project • Define how requirements will be captured and managed • Design and implementation steps • How the development products will be validated, pre-requisites for validation, unit and integration

test coverage targets, other testing techniques • How verification will be performed via reviews and how problems will be handled

V1.0 Page | 29


• General quality assurance topics • Continuous process improvement policy based on project process performance • How the safety office will conduct the project evaluation on completion • How the development process used maps to the IEC61508-1 safety life cycle • Specify the actions and deliverables which have to be provided to fulfil the safety requirements as

defined in IEC61508-1, section 6. • Trigger the creation of the System Safety Requirements Specification and the Software Safety

Requirements Specification. • Define the safety life cycle related activities in detail and who does what • Map design and safety activities and methods to IEC61508-3, Table A.1 and Table A.4 • State design and implementation methods • Project staff qualifications and training • Define validation activities: Software safety testing analysis • Define verification activities: Software safety internal assessment by the safety manager • Define change and configuration management activities • Define gate requirements • Tooling analysis – tool qualifications/certification • List all tools to be used e.g. compilers, debuggers, test tools, static analysers etc. • Documentation and traceability management mapping to IEC61508-1, clause 5 • Define how traceability will be achieved • Define how the safety case report will be generated • Define how gate requirements relate to milestones • Define impact analysis methods.

V1.0 Page | 30


5.2 Safety Case Report The Safety Case Report summarizes all the information relating to the top-level operation of the software, the context in which the software will be used and the main conditions under which testing was performed. A safety claim is made which states at a high level why the software is suitable for use at the stated SIL. A typical SIL3 safety claim is given below. The safety claim made in this project is: The project has been executed according to the process requirements mentioned in IEC61508 to reach SIL 3. The most important aspects are that: All items are traceable. Full impact analysis has been performed at each change. Thorough verification and validation processes are in place and have been executed. Deviations have been documented in detail. Risk reduction is as low as is reasonably practicable. The product delivered herewith is assumed to be XXXXX. It is software which ensures correct functioning of hardware. A series of safety arguments related to the development process are then presented such as: 5.3 Hazard and risk analysis; risk reduction steps This examines the failure modes of the software and the underlying hardware and states how any safety hazards from the failure are mitigated i.e. how the overall system can be brought to a safe state. 5.4 Traceability The methods and tools employed to give full traceability are given and a statement made that all requirements have been correctly implemented and verified and that there is no dead code i.e. code that does not relate to a requirement. A separate traceability report is usually required, which presents the traceability from requirements to test cases in a matrix form that supports the claim. 5.5 Resources The company human resources policy regarding employee education and training is often quoted to demonstrate that all staff engaged with the project have the required skills. Where this is not the case, the means of identifying training needs is stated. 5.6 Tooling The safety qualifications of the development tools used on the project is stated and a statement is made that the consequences of tool failure have been evaluated.

V1.0 Page | 31


5.7 Documentation A statement is given about a check of the release status of documents being made at project milestones. In addition, checking is made of the adherence to the IEC61508 development process through Gate Requirements. 5.8 Process Metrics Finally development process metrics are listed. This is an area which any existing project that is being considered for IEC61508 accreditation is unlikely to address. As IEC61508 expects adherence to a well defined development process, it is not surprising that it demands information on the performance of the process. It summarizes the number of outstanding change requests (CR), problem reports (PR) and the effort per requirement, as shown in section 3.3.9. The Safety Case Report then sets out the results of the testing of the software system itself. Various product metrics are required, such as a summary of MISRA exceptions for the project, MISRA exceptions listed by source file and actual MISRA rules violated. A justification for each rule violation is also given (see 3.3.8). Various source code metrics are usually required such as cyclomatic complexity, maximum call depth, comment density etc. for each module and function (see 3.3.9). Tests results from unit and integration testing are stated, along with the % coverage obtained. The coverage is stated for both requirements (what percentage of requirements have been tested) and code (what percentage MCDC was achieved). Where 100% is not reached for either form of coverage, a justification must be given. For SIL3 though, 100% requirements coverage is essential. The main results files are referenced as supporting evidence. Other relevant results information might be:

1. Outstanding compiler or linker warnings, with a justification of why they cannot be eliminated and what their significance is.

2. Testing results of a more qualitative nature, from diverse sources such as field testing, stress tests or failure response tests, can be given as additional evidence.

3. Performance figures – e.g. max and min runtime for critical functions. This is useful for hard real time control systems, but can be difficult to do without a traditional emulator (although chips like TriCore and Cortex have built-in facilities for this).

V1.0 Page | 32


6 Traceability Requirements traceability is possibly the single most important challenge in IEC61508 developments, especially when applied to existing projects. It is essential to show that all requirements (both functional and safety) have been met. Thus from every Software Requirement Specification item, there must be a traceability path through to a test of some sort. The typical traceability path is:

1. Software Requirement Specification (SRS) 2. Architectural Design Specification (ADS) 3. Detailed Design Specification (DDS) 4. Unit Test Specification (UTS) 5. Integration Test Specification (ITS) 6. Software Validation Test Specification (STS)

The linkage for traceability through the documentation runs something like:

SRS ADS DDS UTS ITS STS

DDSx UTSx

DDSy UTSy

Traceability Links

One test that any IEC61508 assessor will make is to check that a route can be easily seen from start to finish. The linkage runs in both directions, which can be a problem to achieve using simple methods like spreadsheets. Here, for every SRS item a test must be shown to exist. In practice this is not easy to do unless some kind of requirements management tool is used such as DOORS, Rectify, RequisitePRO etc. It is possible to use spreadsheets to show matrices of requirements and tests, but this can soon get unwieldy on large projects as several linked work sheets will be required. Typically these are the matrices needed to show traceability:

V1.0 Page | 33


1. Requirements vs. ‘C’ Functions and Software Processes 2. Requirements vs. Software Processes 3. ‘C’ functions vs. Test Paths 4. Test-Paths vs. TestCases

However the real problem is showing reverse traceability, where each test needs to be traced back to a requirement. This is very difficult without some kind of automation. Generating the traceability links for an existing project is a major task and a requirements management tool is probably more critical than for a project which was built up using the spreadsheet traceability approach. 7 Conclusion It is possible to get an existing project certified to IEC61508, but the challenge of doing this should not be underestimated. The difficulty is greatly dependent on the robustness of the development processes already in existence, the standard of testing and, perhaps most importantly, how the existing work has been documented. Hitex UK has been involved in several customer projects aimed at getting existing projects certified to IEC61508 SIL2 and recently was involved in the certification of a new product at SIL3. Hitex UK can provide assistance when first evaluating a project for possible assessment, to gauge the feasibility of the exercise and highlight the areas where there are major gaps. Hitex can also recommend certification bodies in the UK and Germany that are experienced in assessing deeply embedded systems that can complete the certification process. 8 References

1. "Functional Safety: A straightforward guide to applying IEC61508 and related standards", David Smith And Kenneth Simpson, Elsevier

2. "Software safety by the numbers", Jeff Payne, Exida.com 3. International Electrotechnical Commission, "IEC 61508:2000, Parts 1-7, Functional Safety of Electrical/

Electronic/ Programmable Electronic Safety-Related Systems," 2000.

Find out more… Please contact Hitex on 024 7669 2066.