Software Development explained in Detail

• IEC 61508 Part 3 covers specific requirements for safety-related

software.
• As in other parts of the standard, a safety lifecycle is to be used as the
basis of requirements compliance.
• Figure on next slide shows the software safety lifecycle which is an
expanded plan for Phase 9 of the overall safety lifecycle from Part 1
and is closely linked with the hardware lifecycle.
• As for the overall safety lifecycle, there are requirements for a
functional safety management plan and safety requirements
specification, including all verification and assessment activities
Software Development explained
• The major phases of the software safety lifecycle are shown in Figure
as below
Software Development explained in Detail
• Appropriate quality and safety assurance procedures must be
included. Each step of the software safety life cycle must be divided
into elementary activities with the functions, inputs and outputs
specified for each phase. The standard has complete details of
example software safety lifecycle. During each step of process,
appropriate “techniques and measures” must be used.
• The End User prefers to use “Certified Functional blocks” because all
the steps as detailed below are already taken care of and are
reviewed and certified by third party like TUV SUD.
Software Safety Requirements Specification
• The requirements for software safety shall be sufficiently detailed to
allow design and implementation and to allow a functional safety
assessment.
• Software developers should review the document to verify that it
contains sufficient details. It should be noted that this is often
another iterative process.
• The requirements must be clear, precise, verifiable, testable,
maintainable, and feasible. The requirements must also be
appropriate for the safety integrity level and traceable back to the
specification of the safety requirements of the safety-related system.
Software Validation Plan
• A plan must be set up to demonstrate that the software satisfies the
safety requirements set out in the specification. A combination of
analysis and testing techniques is allowed and the chosen techniques
must be specified in the plan which must consider:
• Required equipment.
• Who will be in charge of the validation & When it will be done
• The modes of operation to be validated like: Start Up, Reset, Manual,
automatic, Shut down
• Reasonably foreseeable abnormal conditions.
• Expected results and pass/fail criteria.
Integration and testing
• Tests of the integration between the hardware and software are
created during the design and development phases and specify the
following:
• Test cases and test data in manageable integration sets.
• Test environment, tools, and configuration.
• Test criteria.
• Procedures for corrective action on failure of test.
The integration testing results shall state each test and the pass/fail
results.
Software verification
• The software verification process tests and evaluates the results of
the software safety life cycle phases to insure they are correct and
consistent with the input information to those phases.
• A verification report must include an explanation of all activities and
results. Verification must be performed on:
• Software safety requirements, Software architecture design, Software
system design
• Software module design, Software source code, Data
• Software module testing, Software integration testing, Hardware
integration testing
• .Software safety requirements testing
Software Validation
• Software validation is done as an overall check to insure that the
software design meets the software safety requirements and
must include the appropriate documentation. The validation may be
done as part of overall system validation or it may be done separately
for the software.
• Testing must be the primary method of validation with analysis used
only to supplement. All tools used in the validation must be calibrated
and an approved, quality system must be in place.
• If validation is done separately for the software, the validation must
follow the software safety validation plan.
Operator Interface7

Check lists-Operator Interface

Item
Item Yes No N/A Comments
#

7.1 Has failure (loss) of the interface been considered?

Are alternate means available to bring the process
7.2 to
a safe state?
Are the following information shown on the
7.3 interface:
1 Where the process is in sequence?
2 Indication that a SIF action has occurred?
3 Indication that a SIF function is bypassed?
Indication that a SIF component or subsystem has
4 failed or is in a degraded state?
5 Status of field devices?
Is the update time appropriate for the application
7.4 under emergency conditions?
Have the operators been checked for color
7.5 blindness?
Is it possible to change SIS program logic from the
7.6 operator interface?
Do parameters that can be changed have security
7.7 access protection?
Check Lists- Communication
Item Item Yes No N/A Comments
#
Can communication failures have an adverse affect
9.1 on the SIS?
Are communication signals isolated from other
9.2 energy sources?
Has write protection been implemented so that
9.3 external systems cannot corrupt SIS memory?
If not, why?
Are interfaces robust enough to withstand EMI/RFI
9.4
And power disturbances?
Check Lists- Application Logic requirements
Item Item Yes No N/A Comments
#
Do all parties have a formal revision and release
12.1 control program for application logic?
Is the logic written in a clear and unambiguous
12.2 manner that is understandable to all parties?

12.3 Does the program include comments?

Within the logic specification, is there a clear and
12.4 concise statement of:

1 Each safety-related function (SIF)?

2 Information to be given to the operators?
The required action of each operator command,
3 including illegal or unexpected commands?
The communication requirements between the SIS
4 and other equipments?
The initial states for all internal variables and
5 external interfaces?

6 The required action for out-of-range variables?

Check List- Embedded Software
Item Item Yes No N/A Comments
#
Can the vendor provide evidence of an independent
13.1 safety assessment of all embedded software?
Has the software been used in similar applications
13.2 for a significant period of time?
Is the vendor software documented sufficiently for
13.3 the user to understand its operation and how to
implement the desired functionality?
Are the results of abnormal math operation fully
13.4 documented?
Are there procedures for the control of software
13.5 versions in use and the update of all similar systems?
For spare which contain firmware, is there a
13.6 procedure to insure all modules are compatible?
13.7 Can software versions in use easily be checked?
If errors are found in embedded software, are they
13.8 reported to and corrected by the vendor, and
incorporated into the SIS only after checking and testing
the corrected code?
Has the vendor made an impact analysis for software
13.9 corrections or changes?
Does the manufacturer provide competent technical
13.10 support?