Engineering masterclass | Functional safety, cybersecurity, software assurance, systems engineering, compliance, and process maturity

Modern vehicles, aircraft, medical devices, railway systems, industrial controllers, and spacecraft depend on software that must operate reliably under demanding conditions. A failure in an ordinary application may cause inconvenience. A failure in a safety-critical system can result in injury, loss of life, environmental damage, or significant operational disruption.

This is why safety-critical engineering requires more than good programming, automated testing, or conventional quality assurance.

It requires disciplined systems engineering, hazard and risk analysis, requirements traceability, verification and validation, configuration management, controlled changes, independent assurance, and defensible evidence.

This tutorial series explains 12 important standards and frameworks, how they work, where they apply, how engineering teams implement them, and how they fit together.

1. Understanding the 12 standards

#	Standard or framework	Primary application	Central objective
18	ISO 26262	Automotive	Functional safety of road-vehicle E/E systems
19	ISO/SAE 21434	Automotive	Cybersecurity risk management
20	IEC 61508	Industrial and cross-sector	Functional safety of E/E/PE systems
21	DO-178C	Aviation	Airborne software development assurance
22	DO-254	Aviation	Airborne electronic hardware design assurance
23	IEC 62304	Medical technology	Medical-device software lifecycle
24	ISO 13485	Medical technology	Quality management systems
25	EN 50128 / EN 50716	Railways	Railway software development assurance
26	ISO/IEC/IEEE 12207	Cross-industry	Software lifecycle processes
27	ISO/IEC/IEEE 15288	Cross-industry	Systems lifecycle processes
28	ISO/IEC 29110	Very small entities	Tailored systems and software engineering
29	SPICE for Space	Space industry	Software process assessment and improvement

2. An important clarification: these standards do different jobs

They should not all be treated as competing maturity models.

Conceptual classification. These categories overlap: a single project may need several standards simultaneously.

For example, an automotive braking controller may use ISO 26262 for functional safety, ISO/SAE 21434 for cybersecurity, ISO/IEC/IEEE 15288 for systems engineering processes, and ISO/IEC/IEEE 12207 for software engineering processes.

The standards complement one another rather than replacing one another.

3. Current editions and important changes

Several details matter when designing a training program or preparing a compliance roadmap.

• ISO/IEC/IEEE 12207: A new 2026 edition supersedes the 2017 edition. IEEE/ISO/IEC 12207-2026
• Railway software: EN 50716:2023 replaces EN 50128 and EN 50657 in the relevant European standards framework. Existing project contracts may still cite earlier editions. EN
• IEC 61508: The 2010 editions remain listed as valid, while third-edition prerelease publications appeared in October 2026. The applicable edition must be confirmed for each project. IEC+1
• ISO 26262: The 2018 edition remains published while the next revision is under development. Part 1: Vocabulary
• ISO/SAE 21434: The 2021 edition remains published, with a successor under development. Road vehicles — Cybersecurity engineering
• IEC 62304: The published baseline remains IEC 62304:2006 with Amendment 1:2015. IEC
• ISO 13485: The 2016 edition was reconfirmed in 2025. Requirements for regulatory purposes

Edition references are included where necessary to identify the correct publication. The engineering principles themselves are presented without tying their usefulness to a particular calendar year.

Tutorial 18 — ISO 26262: Automotive Functional Safety Engineering

クルマの先進技術を支える「ECU」 | 開発ストーリー | デンソーテン

ADAS and Autonomous Driving Sensors and Electronics Test – NI

Auto-Innovations – Laboratoire CEM de Rüsselsheim : résistance aux ondes électromagnétiques

15

What is ISO 26262?

ISO 26262 is the international functional safety standard for electrical and electronic systems in road vehicles.

It addresses hazards caused by malfunctioning behavior of vehicle E/E systems and establishes engineering practices for reducing unreasonable risks arising from those hazards.

Typical applications include braking, steering, electric propulsion, battery management, powertrain control, airbags, and driver-assistance systems.

ISO 26262 does not mean that a vehicle will never fail. Its purpose is to ensure that safety-related failures are systematically identified, analyzed, controlled, and supported by adequate assurance evidence.

Core concepts

Concept	Explanation
Item	System or function under safety analysis
HARA	Hazard Analysis and Risk Assessment
Safety goal	Top-level safety requirement derived from a hazardous event
ASIL	Automotive Safety Integrity Level
FSC	Functional Safety Concept
TSC	Technical Safety Concept
FMEA	Failure Modes and Effects Analysis
FTA	Fault Tree Analysis
FMEDA	Failure Modes, Effects and Diagnostic Analysis
Safety case	Structured argument, supported by evidence, for acceptable safety

Understanding ASIL

ISO 26262 introduces four Automotive Safety Integrity Levels: ASIL A, B, C, and D, with ASIL D representing the most demanding integrity level. Quality Management (QM) applies when ASIL-specific requirements are not assigned.

ASIL determination considers:

• Severity of potential harm
• Exposure to the operational situation
• Controllability by people involved

ASIL is not calculated from severity alone.

ASIL classification overview

QM

ASIL A

ASIL B

ASIL C

ASIL D

Illustration of increasing assurance rigor, not a quantitative risk or failure-probability scale.

Step-by-step implementation

Step 1: Define the item and its boundaries

Suppose a team is developing an electronic braking controller.

Identify its functions, operating conditions, hardware and software components, external interfaces, assumptions, and interactions with other vehicle systems.

Create an item definition that establishes precisely what is being analyzed.

Step 2: Perform HARA

Identify hazardous events such as unintended braking, loss of braking assistance, or delayed brake response.

For each hazardous event, evaluate severity, exposure, and controllability using the prescribed classification method.

The resulting safety goals receive appropriate ASIL classifications.

Step 3: Develop the Functional Safety Concept

Transform safety goals into functional safety requirements.

For example:

Safety goal SG-01: Prevent unreasonable risk from unintended braking intervention.

An associated functional requirement might specify that the system detect certain unintended actuation conditions and transition to a defined safe response within an established fault-tolerant time interval.

The exact response and timing must come from the system hazard analysis, not from a generic template.

Step 4: Develop the Technical Safety Concept

Allocate functional safety requirements to hardware, software, and system mechanisms.

Possible mechanisms include independent plausibility checks, watchdog monitoring, sensor redundancy, diagnostic communication, and fault handling.

The architecture must address dependent failures, systematic faults, and relevant random hardware failure behavior.

Step 5: Implement hardware and software

Apply appropriate architectural and coding practices, interface controls, static analysis, design reviews, unit verification, and safety-related software techniques according to the allocated ASIL and relevant standard parts.

Step 6: Perform safety verification and validation

Verify individual components, integrations, and safety mechanisms.

Validate the safety goals in the relevant vehicle context.

Use fault injection where appropriate to demonstrate diagnostic and fault-response behavior.

Step 7: Prepare the safety case

Assemble the argument and supporting evidence demonstrating that the safety goals have been adequately addressed.

Independent confirmation activities and a functional safety assessment may be required according to the applicable standard provisions.

Example traceability

Artifact	Example
Hazard	Unintended braking
Safety goal	SG-01
Functional requirement	FSR-01
Technical requirement	TSR-03
Software requirement	SWR-14
Test	TC-FAULT-07
Evidence	Fault-injection report and reviewed test logs

A traceability matrix should connect the safety goals through requirements and implementation to verification results, including change impact.

Common mistakes

Treating ASIL as a generic software quality score, skipping HARA, assuming 100% code coverage guarantees safety, overlooking hardware-software interactions, and preparing the safety case only at the end of development.

Practical exercise: Create an item definition, sample HARA worksheet, functional safety concept, and traceability matrix for an electronic parking brake controller.

Tutorial 19 — ISO/SAE 21434: Automotive Cybersecurity Engineering

Connected mobility – UTAC

Expertise | STAR ELECTRONICS

BUSMUST｜总线分析硬件、软件生态与系统解决方案

14

What is ISO/SAE 21434?

ISO/SAE 21434 establishes a framework for managing cybersecurity risks throughout the lifecycle of road-vehicle electrical and electronic systems.

Where ISO 26262 concentrates on malfunctioning behavior and functional safety, ISO/SAE 21434 addresses intentional cyber threats, including malicious access, manipulation, compromise, and exploitation.

Potential attack surfaces include vehicle communication networks, telematics, OTA update systems, diagnostic interfaces, wireless connectivity, backend services, and software components.

Key cybersecurity concepts

Term	Meaning
TARA	Threat Analysis and Risk Assessment
Asset	Something of value that requires protection
Damage scenario	Consequence of compromised cybersecurity properties
Attack path	Sequence of steps through which an attack could occur
Cybersecurity goal	High-level protection objective
Cybersecurity concept	Strategy for achieving cybersecurity goals
Vulnerability management	Identification, analysis, and treatment of weaknesses
Cybersecurity case	Structured argument supporting cybersecurity claims

Implementation workflow

Step 1: Establish cybersecurity governance

Assign responsibility for cybersecurity management, organizational processes, competence, supplier interfaces, and monitoring obligations.

Define the cybersecurity management plan for the item or component.

Step 2: Define the system and assets

For a telematics control unit, assets might include firmware authenticity, vehicle control interfaces, cryptographic keys, diagnostic privileges, and customer data.

Document trust boundaries and interfaces with mobile applications, cloud services, and vehicle networks.

Step 3: Perform TARA

Identify damage scenarios, threats, attack paths, feasibility factors, and impact.

For example, consider an unauthorized firmware installation that could enable manipulation of vehicle functions.

Assess the risk according to the selected, documented TARA method.

Step 4: Establish cybersecurity goals

Example:

CSG-01: Prevent unauthorized installation of vehicle control firmware.

Step 5: Derive cybersecurity requirements

Potential requirements include authenticated software updates, integrity checks, secure boot, access control, protected key storage, and rollback protection.

The technical selection must follow the actual threat model and platform capabilities.

Step 6: Design and implement controls

Apply secure development practices, dependency management, security architecture review, interface hardening, and cryptographic key management.

Step 7: Verify cybersecurity controls

Test authentication failures, modified firmware packages, unauthorized diagnostic access, network message abuse, and update interruptions.

Perform penetration testing with authorization and a controlled scope.

Step 8: Manage post-development cybersecurity

Maintain vulnerability monitoring, incident response, coordinated disclosure, software update processes, and supplier security coordination.

Cybersecurity assurance continues during operations and maintenance.

Example automotive TARA worksheet

Asset	Threat scenario	Potential damage	Candidate treatment
Firmware	Unauthorized modification	Unsafe or compromised behavior	Signed updates and secure boot
Diagnostic interface	Privilege abuse	Unauthorized vehicle operations	Strong authorization
OTA channel	Package tampering	Installation of malicious software	Signature and integrity verification
Vehicle network	Spoofed messages	Incorrect system behavior	Message validation and network protection

These are starting examples, not completed risk assessments.

ISO 26262 versus ISO/SAE 21434

Dimension	ISO 26262	ISO/SAE 21434
Main concern	Functional safety	Cybersecurity
Typical initiating concern	Malfunction	Cyber threat
Primary analysis	HARA	TARA
Classification	ASIL	Cybersecurity risk treatment
Lifecycle	Safety lifecycle	Cybersecurity lifecycle
Supporting argument	Safety case	Cybersecurity case

Safety and cybersecurity often intersect. A compromised controller may create a hazardous system state even when its components are functioning exactly as commanded.

Practical exercise: Perform a simplified TARA for an OTA firmware update feature, then map cybersecurity goals to software requirements and security test cases.

Tutorial 20 — IEC 61508: Functional Safety of Industrial and Programmable Systems

S7-1500 Safety (F-CPU) Guide: 1515F vs 1516F vs 1517F – Rabwellplc

What Is an Emergency Shutdown System? – RealPars

מדריך פתרון תקלות למודול קלט/פלט של Triconex SIS | אבחון ותיקון תקלות TMR – Industrial Control Hub

10

What is IEC 61508?

IEC 61508 is a foundational functional safety standard for electrical, electronic, and programmable electronic safety-related systems.

Its principles support safety engineering across multiple industries and underpin several sector-specific standards.

It addresses systematic faults, random hardware failures, safety lifecycle management, and the integrity of safety functions.

Safety Integrity Levels

IEC 61508 uses Safety Integrity Levels from SIL 1 through SIL 4.

The selected SIL expresses the required integrity of a safety function, not the general quality of an entire factory or product.

For low-demand safety functions, commonly referenced target average probability-of-failure-on-demand bands are:

SIL	Average probability of dangerous failure on demand (PFDavg)
SIL 1	≥10⁻² to <10⁻¹
SIL 2	≥10⁻³ to <10⁻²
SIL 3	≥10⁻⁴ to <10⁻³
SIL 4	≥10⁻⁵ to <10⁻⁴

These ranges apply to low-demand operation. High-demand or continuous-operation functions use dangerous failure probability per hour (PFH) criteria instead.

Also, a numeric failure-rate target alone does not establish SIL capability. Architectural constraints and systematic capability must be addressed.

Step-by-step implementation

Step 1: Define the equipment under control

Identify the industrial process, operating conditions, foreseeable hazards, interfaces, and existing risk controls.

Step 2: Identify hazards and estimate risk

Use appropriate analysis methods such as HAZOP, FMEA, fault trees, or other justified techniques.

Step 3: Define safety functions

Example:

If a process vessel exceeds its defined safe pressure limit, the safety system shall initiate a protective shutdown.

Step 4: Determine the required integrity

Determine the necessary risk reduction and assign the SIL using an appropriate risk assessment method.

Step 5: Allocate safety requirements

Define the sensing, logic-solving, and final-element responsibilities.

Step 6: Design the safety architecture

Consider diagnostic coverage, redundancy, fault tolerance, proof testing, common-cause failures, and independence.

Step 7: Verify implementation

Evaluate software, hardware, timing, diagnostics, failure responses, and safety-function performance.

Step 8: Validate and operate

Demonstrate that the complete installed safety function satisfies its requirements and establish maintenance, proof-testing, modification, and operational controls.

Example safety function

Illustrative sensor–logic–final element architecture. Real designs require analysis of all failure modes, including common-cause failures.

For the safety function, document the required response time, failure states, proof-test interval, environmental constraints, and diagnostic assumptions.

Do not assign an SIL simply because a particular controller is marketed as SIL-capable.

Practical exercise: Develop a safety requirements specification and proof-test outline for an emergency shutdown function.

Tutorial 21 — DO-178C: Airborne Software Development Assurance

Virtual flight-test campaign and lab test paving way for A321XLR’s first flight | Airbus

GNC Subsystems | TUM – Institute of Flight System Dynamics

Collins Delivers Avionics for NASA’s Supersonic X-59 | Aviation International News

10

What is DO-178C?

DO-178C, Software Considerations in Airborne Systems and Equipment Certification, provides objectives and guidance for airborne software development assurance.

It is used within aircraft certification programs to demonstrate that software was developed and verified through suitable controlled processes.

The FAA recognizes DO-178C through Advisory Circular AC 20-115D as an acceptable means, but not the only means, of demonstrating compliance with relevant airworthiness requirements. FAA

DO-178C is objective-based rather than a mandate to use a particular programming language, framework, or software development methodology.

Software levels

Level	Failure-condition classification	Relative assurance rigor
A	Catastrophic	Highest
B	Hazardous	Very high
C	Major	High
D	Minor	Lower
E	No safety effect	No DO-178C objectives assigned

The software level is derived from the aircraft/system safety assessment process, not from the programming language or codebase size.

Implementation steps

Step 1: Establish certification planning

Prepare the Plan for Software Aspects of Certification (PSAC) and supporting development, verification, configuration management, and quality assurance planning.

Coordinate expectations with the applicable certification authority and relevant stakeholders.

Step 2: Develop high-level requirements

Translate allocated system requirements into verifiable software requirements.

Step 3: Develop low-level requirements and architecture

Refine detailed software behavior and architectural interfaces.

Step 4: Implement source code

Use controlled coding standards, source review, configuration management, and implementation practices.

Step 5: Verify software

Perform requirements-based testing and applicable reviews and analyses.

Demonstrate verification coverage appropriate to the software level.

Step 6: Analyze structural coverage

For the applicable software level, analyze statement, decision, and Modified Condition/Decision Coverage (MC/DC) as required by the relevant objectives.

MC/DC is particularly important for Level A software. It demonstrates that each condition in a decision can independently affect the decision outcome, subject to the applicable coverage interpretation and constraints.

Coverage evidence cannot replace requirements-based testing.

Step 7: Resolve verification gaps

Investigate uncovered code, unintended functionality, anomalies, and requirement or test deficiencies.

Step 8: Assemble certification evidence

Prepare lifecycle data including traceability, verification results, configuration records, problem reports, and the Software Accomplishment Summary (SAS).

Example traceability

Aircraft System Requirement
          |
          v
High-Level Software Requirement
          |
          v
Low-Level Software Requirement
          |
          v
Software Architecture / Source Code
          |
          v
Requirements-Based Tests
          |
          v
Coverage Analysis and Verification Evidence

Bidirectional traceability is important for understanding whether requirements are implemented and verified, and whether implementation has appropriate justification.

Supporting publications

DO-178C has related publications addressing tool qualification (DO-330), model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333). Their applicability depends on the development approach. FAA

Practical exercise: Build a small requirements-based verification package for an avionics monitoring module, including a requirements-to-tests matrix and structural coverage report.

Tutorial 22 — DO-254: Airborne Electronic Hardware Design Assurance

Aerospace & Defense: Embedded Solutions | GSAS India

News | The ‘fuse box’ of electrified flight | RTX

Trusted Aerospace Computing Experts Since 1996 | Xiphos

10

What is DO-254?

DO-254, Design Assurance Guidance for Airborne Electronic Hardware, addresses development assurance for airborne electronic hardware.

It is particularly relevant to complex electronic hardware, including certain FPGA, ASIC, and other custom hardware implementations.

The FAA’s AC 20-152A recognizes DO-254/ED-80 and provides further guidance for custom devices, COTS intellectual property, COTS devices, and circuit board assemblies. FAA

DO-178C versus DO-254

Area	DO-178C	DO-254
Primary subject	Software	Electronic hardware
Main artifacts	Software requirements, code, tests	Hardware requirements, design data, verification
Typical implementation	Embedded executable software	FPGA, ASIC, other electronic hardware
Verification	Software reviews, tests, analysis	Hardware reviews, simulation, tests, analysis
Assurance determination	Software level	Hardware design assurance level

Implementation workflow

Step 1: Classify the hardware and establish assurance needs

Determine the applicable design assurance level and the guidance relevant to the hardware’s complexity and function.

Step 2: Prepare hardware development and verification plans

Document design methods, verification methods, configuration management, process assurance, and certification coordination.

Step 3: Establish hardware requirements

Create verifiable functional, performance, timing, environmental, and interface requirements.

Step 4: Develop hardware architecture and detailed design

Implement the required circuits, programmable logic, and interfaces.

For an FPGA, activities may include RTL development, simulation, synthesis, place-and-route, and hardware implementation verification.

Step 5: Verify requirements

Use appropriate simulation, analysis, hardware testing, inspection, and independent review.

Confirm the implemented design satisfies its requirements.

Step 6: Control design changes

Assess modifications to logic, timing, synthesis tools, IP blocks, hardware configurations, and verification results.

Step 7: Compile assurance evidence

Maintain traceability, verified design baselines, discrepancy records, and required lifecycle data.

FPGA example

Consider a hardware watchdog monitoring an avionics processor.

Its requirements may cover watchdog timing, reset behavior, power-on state, clock dependencies, fault response, and output interfaces.

Verification should investigate boundary timing conditions, implementation-specific behavior, clock failures, and relevant failure modes.

Simulation alone does not necessarily establish adequacy of the final hardware implementation.

Practical exercise: Define a hardware requirements specification and verification matrix for an FPGA-based watchdog circuit.

Tutorial 23 — IEC 62304: Medical Device Software Lifecycle Engineering

SystemView for IEC 62304 Medical Device Evidence… | GSAS

Securing the Lifeline: A Guide to Medical Device Penetration Testing | AppSec Labs

【即時新聞】迎設備換機潮！ICU Medical(ICUI)毛利率看升，預告明年買回庫藏股 | CMoney投資網誌

11

What is IEC 62304?

IEC 62304 is an international standard establishing software lifecycle requirements for medical devices.

It applies when software forms part of a medical device and when software itself is a medical device, often called Software as a Medical Device (SaMD).

Examples include patient monitoring applications, infusion pump controllers, medical imaging software, software-based diagnostic systems, and connected medical devices.

The standard addresses software development, maintenance, risk-management interfaces, configuration management, and software problem resolution. It does not, by itself, cover every aspect of complete medical-device validation or final device release. IEC

Software safety classes

IEC 62304 uses software safety Classes A, B, and C.

Class	General classification concept
A	Software failure cannot contribute to a hazardous situation, or residual risk is acceptable under the applicable classification provisions
B	Software failure could contribute to a hazardous situation that can result in non-serious injury
C	Software failure could contribute to a hazardous situation that can result in death or serious injury

Classification must follow the standard’s applicable rules, including consideration of risk controls external to the software. It must not be based merely on how complex the software looks.

Step-by-step implementation

Step 1: Define the medical software system

Identify intended use, users, operating environment, patient interactions, interfaces, and software boundaries.

For example, consider software controlling a patient infusion pump.

Step 2: Establish risk-management interfaces

Connect software lifecycle activities to medical-device risk management, typically under ISO 14971.

Identify how software-related failures could contribute to hazardous situations.

Step 3: Determine software safety classification

Evaluate the software system and relevant items using the classification rules.

Document assumptions, risk controls, and the rationale for the assigned class.

Step 4: Prepare the software development plan

Include lifecycle activities, responsibilities, deliverables, verification strategy, configuration management, and problem-resolution procedures.

Step 5: Develop software requirements

Requirements should cover functional behavior, interfaces, data processing, alarms, fault handling, and relevant risk-control functionality.

Step 6: Design software architecture

Partition the system into appropriate software items, define interfaces, and document architectural decisions.

Where safety classification depends on segregation, demonstrate that the segregation is effective.

Step 7: Implement and verify software

Develop units, perform appropriate verification, integrate components, and verify the software system.

Apply the activities required for the selected safety classes.

Step 8: Manage release and maintenance

Resolve or appropriately evaluate anomalies, establish release records, maintain configuration baselines, and control post-release modifications.

Practical example: Infusion pump

Suppose a programmable infusion pump must prevent medication delivery beyond a specified safe limit.

The software team might define:

Artifact	Example
Hazardous situation	Patient receives excessive medication
Software requirement	Enforce configured delivery limits
Risk control	Independent delivery-rate monitoring
Verification	Boundary-value and fault-response testing
Maintenance activity	Assess safety impact of software updates

An actual device requires additional hazard analysis, risk evaluation, architecture, and verification beyond this simplified example.

Important companion standards

IEC 62304 is commonly used alongside ISO 13485 for quality management, ISO 14971 for medical-device risk management, and applicable device-specific safety, usability, cybersecurity, and regulatory requirements.

It is incorrect to assume that IEC 62304 compliance alone establishes medical-device regulatory approval.

Practical exercise: Develop a software development plan, risk-control traceability matrix, and software verification strategy for a patient monitoring application.

Tutorial 24 — ISO 13485: Medical Device Quality Management Systems

ISO 13485 para Dispositivos Médicos: Implementação Prática do Sistema de Gestão da Qualidade | Engenharia Biomédica

Working at MicroVention | Great Place To Work®

FDA’s Revised QMSR Modernizes Device Quality Regulation – Gardner Law

11

What is ISO 13485?

ISO 13485 specifies quality management system requirements for organizations involved in medical-device lifecycles.

Its purpose is to help organizations consistently meet applicable customer and regulatory requirements.

Unlike IEC 62304, which focuses on medical software lifecycle activities, ISO 13485 addresses the broader organizational quality management system.

The standard covers processes associated with design and development, purchasing, production, monitoring, measurement, control of nonconforming product, corrective action, documentation, and other QMS obligations.

Core QMS elements

Element	Purpose
Quality manual and documented processes	Establish the QMS framework
Document control	Ensure approved information is available and controlled
Record control	Preserve quality evidence
Design and development controls	Manage product development
Supplier controls	Manage purchased products and services
Risk management	Integrate risk-based controls into relevant processes
Internal audits	Evaluate QMS conformity and effectiveness
CAPA	Correct nonconformities and address their causes
Management review	Evaluate organizational quality performance
Traceability and production controls	Support product quality and regulatory needs

Step-by-step implementation

Step 1: Determine QMS scope

Identify products, locations, outsourced activities, regulatory markets, organizational responsibilities, and relevant exclusions or non-applicability justifications.

Step 2: Establish quality policy and objectives

Define measurable quality objectives such as complaint resolution effectiveness, audit findings, supplier performance, and process nonconformity rates.

Step 3: Establish document and record control

Implement controlled procedures for approval, revision, access, retention, and obsolete-document handling.

Step 4: Implement design and development controls

Define design inputs, outputs, reviews, verification, validation, transfer, and design changes.

Step 5: Control suppliers

Classify suppliers based on the importance of their supplied goods and services.

Evaluate, select, monitor, and re-evaluate suppliers using defined criteria.

Step 6: Establish nonconformity and CAPA processes

Ensure problems are documented and evaluated.

Apply appropriate corrections, investigate root causes when needed, implement corrective actions, and verify effectiveness.

Step 7: Conduct internal audits

Assess whether organizational processes comply with the QMS and applicable requirements.

Step 8: Conduct management reviews

Review quality performance, audit findings, CAPA effectiveness, customer feedback, regulatory changes, and improvement opportunities.

Step 9: Prepare for external assessment

If certification is sought, select an appropriate certification body, resolve identified gaps, and complete the necessary assessment process.

CAPA example

A medical-device manufacturer discovers repeated failures in a sensor calibration process.

A weak response would be to recalibrate the affected units and close the issue.

A stronger CAPA process evaluates the root cause, affected production batches, product risk, corrective actions, supplier implications, effectiveness verification, and the need for preventive system improvements.

ISO 13485 versus IEC 62304

ISO 13485	IEC 62304
Organizational quality management	Medical software lifecycle
Broader operational processes	Software-specific engineering
Supplier and production controls	Software requirements and verification
Management review and internal audit	Software change and problem resolution
QMS certification possible	Not a standalone device approval

Practical exercise: Build a QMS process map and CAPA workflow for a software-enabled medical-device manufacturer.

Tutorial 25 — EN 50128 and EN 50716: Railway Software Safety Engineering

Railway Signal Control Systems Safety Checks

G.G. Tronics

Live testing of E-W Line’s new signalling system on Sundays | The Straits Times

12

What are EN 50128 and EN 50716?

EN 50128 historically established requirements for software used in railway control and protection systems.

EN 50716:2023 is the successor covering software development for railway signalling and onboard rolling-stock applications, consolidating the scope previously addressed by EN 50128 and EN 50657 in the European framework. EN

Railway software must operate reliably across complex environments involving train movement, interlocking, track occupancy, signalling, braking, communications, and operator control.

The consequences of incorrect software behavior can be severe.

Railway safety standards ecosystem

Standard	Focus
EN 50126 series	RAMS lifecycle and management
EN 50129	Safety-related electronic systems for signalling
EN 50716	Railway software development
EN 50128	Legacy railway software requirements
EN 50657	Legacy rolling-stock software requirements

RAMS refers to Reliability, Availability, Maintainability, and Safety.

Railway development commonly involves coordinated systems engineering and safety assurance across these publications.

Understanding railway SIL

Railway safety functions may be allocated SIL 1 through SIL 4 based on the applicable safety assessment and architecture.

SIL 4 generally corresponds to the most demanding safety integrity expectations.

However, it is important not to confuse railway SIL allocation rules with every aspect of IEC 61508 SIL determination. Similar terminology does not make the complete standards interchangeable.

Step-by-step implementation

Step 1: Establish system safety context

Define the railway application, operational environment, interfaces, safety responsibilities, and applicable standards.

Step 2: Allocate software safety requirements

Translate system-level safety requirements into verifiable software requirements and identify the relevant integrity level.

Step 3: Establish the software assurance plan

Define lifecycle activities, methods, responsibilities, verification, validation, independence, and required documentation.

Step 4: Develop architecture

Design software components with suitable control of interfaces, failures, timing behavior, and safety-related dependencies.

Step 5: Implement the software

Apply appropriate design practices, coding methods, static analysis, reviews, and configuration management.

Step 6: Verify the implementation

Use requirements-based testing, integration tests, boundary-value tests, fault testing, and applicable analysis techniques.

Step 7: Validate system behavior

Validate the software within the intended railway operational context, including relevant interactions with hardware and external systems.

Step 8: Assemble the software safety evidence

Maintain requirements traceability, verification reports, anomaly records, change histories, and evidence required for the project’s assurance process.

Example: Railway interlocking

A railway interlocking system controls routes and prevents incompatible train movements.

One illustrative safety requirement is:

RSR-01: The system shall not authorize conflicting routes simultaneously.

Verification may include route-conflict matrices, state-transition testing, fault injection, and integration testing with simulated or actual signalling equipment.

The complete safety argument must also consider hazards arising from interfaces, equipment faults, communications, and operational conditions.

Important migration guidance

For a new railway project, evaluate EN 50716 rather than automatically starting with EN 50128. For an existing project, determine which edition is specified by the contract, approving authority, national rules, and approved project baseline.

Practical exercise: Create a railway interlocking requirements-to-tests matrix and a software assurance plan aligned with the applicable railway standard.

Tutorial 26 — ISO/IEC/IEEE 12207: Software Lifecycle Process Engineering

Top Embedded System Design and Software Development Services in Bangalore | Expert Solutions | Knowx Innovations

BUSMUST｜总线分析硬件、软件生态与系统解决方案

2026 Fastest Online Information Technology management Degree Programs Ranking in the South | Research.com

11

What is ISO/IEC/IEEE 12207?

ISO/IEC/IEEE 12207 establishes a framework for software lifecycle processes.

It supports software engineering from initial concept and acquisition through development, operation, maintenance, and retirement.

The currently published ISO/IEC/IEEE 12207:2026 edition aligns with ISO/IEC/IEEE 15288:2023, helping organizations coordinate software engineering with broader systems engineering. Software life cycle processes

The standard is process-oriented.

It does not prescribe a single development methodology or insist that software must be built using a waterfall model.

Main process areas

Organizations can use the standard to organize activities such as:

Process area	Typical activities
Agreement processes	Acquisition and supply
Organizational project-enabling processes	Infrastructure, quality, knowledge, lifecycle management
Technical management processes	Planning, risk, configuration, measurement, decision management
Technical processes	Requirements, architecture, design, implementation, integration, verification, validation, operations, maintenance, disposal

The process groups are used to establish accountability, objectives, activities, and outcomes.

Step-by-step implementation

Step 1: Identify the software system

Document stakeholders, business objectives, scope, requirements, interfaces, and operational expectations.

Step 2: Select applicable lifecycle processes

Determine which processes are necessary for the system, organization, suppliers, and contractual obligations.

Tailor processes with documented justification.

Step 3: Define process ownership

Assign responsibilities for requirements, design, development, verification, configuration, release, support, and maintenance.

Step 4: Establish engineering work products

Define the requirements specification, architecture description, design records, test plans, configuration baselines, and acceptance evidence.

Step 5: Integrate processes into delivery

Map engineering activities into the organization’s delivery method.

For an Agile organization, this might involve backlog refinement, architecture decisions, pull-request reviews, automated testing, release governance, and retrospective improvement.

Step 6: Establish verification and validation

Differentiate between confirming that a work product satisfies its specified requirements and confirming that the overall solution meets its intended use and stakeholder needs.

Step 7: Manage operations and maintenance

Establish incident management, corrective maintenance, controlled software changes, and support procedures.

Step 8: Measure and improve processes

Track performance indicators that reflect process effectiveness, including defect escape rates, requirement instability, review findings, verification completion, and release reliability.

Example: Embedded firmware delivery

A development team building industrial firmware might define:

Stakeholder Needs
       |
       v
Software Requirements
       |
       v
Software Architecture
       |
       v
Detailed Design & Implementation
       |
       v
Integration & Verification
       |
       v
System Validation
       |
       v
Release, Operation & Maintenance
       |
       v
Retirement

This illustrates relationships between lifecycle activities, not a requirement to complete all work in a strictly sequential manner.

Activities can repeat or overlap.

Practical implementation with DevOps

CI/CD can support ISO/IEC/IEEE 12207 processes by collecting traceability, build logs, test results, static analysis reports, release approvals, and configuration records.

However, CI/CD automation does not replace engineering judgment, risk management, acceptance decisions, or required reviews.

Practical exercise: Map an existing software delivery pipeline to lifecycle processes, identify missing work products, and define a process improvement backlog.

Tutorial 27 — ISO/IEC/IEEE 15288: Systems Lifecycle Engineering

Simcenter Integration Solutions | Siemens

LAMBDA AeroTech Consulting: Aircraft & System Development Process

U-M’s Automotive Research Center gets $100 million through 2028 | Mechanical Engineering Department – University of Michigan

11

What is ISO/IEC/IEEE 15288?

ISO/IEC/IEEE 15288 establishes a common process framework for the lifecycle of systems.

A system can contain hardware, software, people, procedures, facilities, services, and other interacting elements.

This distinguishes systems engineering from software-only engineering.

The standard is useful for organizations developing complex, multidisciplinary products including automobiles, aircraft, industrial equipment, spacecraft, and medical systems. IEEE/ISO/IEC 15288-2023

Core systems engineering principles

Systems engineering starts by understanding the problem before choosing the technical solution.

It focuses on stakeholder needs, system requirements, architecture, interfaces, integration, verification, validation, operation, and lifecycle considerations.

Step-by-step implementation

Step 1: Identify stakeholders

Determine who uses, operates, maintains, supports, regulates, or is otherwise affected by the system.

Step 2: Define stakeholder needs

Document expected capabilities, constraints, operating scenarios, performance, safety, security, and lifecycle needs.

Step 3: Define system requirements

Transform stakeholder needs into clear, measurable, feasible, and verifiable system requirements.

Step 4: Establish system architecture

Identify system elements, interfaces, responsibilities, and architectural tradeoffs.

Step 5: Allocate requirements

Allocate requirements to software, hardware, mechanical, electrical, human, or procedural elements.

Step 6: Implement system elements

Coordinate the development, acquisition, and construction of system components.

Step 7: Integrate and verify

Verify system elements and their interfaces as the integrated system is built.

Step 8: Validate system suitability

Determine whether the delivered system fulfills the intended stakeholder needs in its operational environment.

Step 9: Transition, operate, maintain, and retire

Manage deployment, user support, operational performance, maintenance, upgrades, and eventual disposal.

The systems engineering V-model

Conceptual V-model showing relationships between system definition and corresponding verification and validation. Iterative development remains possible.

ISO/IEC/IEEE 12207 versus 15288

Dimension	12207	15288
Main scope	Software systems and services	Complete systems
Disciplines	Software-centric	Multidisciplinary
Typical work	Software requirements, architecture, integration	System requirements, architecture, element allocation
Hardware coverage	Interfaces and software context	Explicit system elements
Relationship	Complements 15288	Complements 12207

Practical exercise: Develop a system context diagram, stakeholder needs specification, system requirements matrix, and architecture for an electric vehicle battery management system.

Tutorial 28 — ISO/IEC 29110: Systems and Software Engineering for Very Small Entities

Advanced PCB Design Australia | RF, HDI, DDR, High-Speed Electronics

System Design Interview: Senior Engineer Guide | IT Support Group

Advanced C Programming Course — Free Online, Certificate & Lifetime [2026] | Elevify

7

What is ISO/IEC 29110?

ISO/IEC 29110 provides lifecycle profiles and guidance suited to very small entities, commonly organizations, departments, or projects with up to 25 people.

Smaller engineering teams often lack the resources to implement large enterprise process frameworks in full.

ISO/IEC 29110 provides a more accessible approach to introducing disciplined project management and engineering practices.

The ISO/IEC 29110 series includes Entry, Basic, Intermediate, and Advanced profiles. ISO notes that its profiles are intended primarily for entities not developing critical systems or critical software. ISO

That qualification matters: ISO/IEC 29110 does not replace mandatory sector-specific safety engineering requirements.

Core profiles

Profile	General purpose
Entry	Very small projects and early-stage organizations
Basic	Single-project disciplined engineering
Intermediate	More established and coordinated project execution
Advanced	Further organizational and process capability development

The applicable profile and available guide depend on the software or systems engineering context.

Step-by-step implementation

Step 1: Evaluate organizational size and complexity

Identify team size, project complexity, customer requirements, criticality, and existing processes.

Step 2: Select an applicable profile

Choose a profile appropriate to current capability and business needs.

Step 3: Establish project management

Define project scope, tasks, responsibilities, milestones, risks, and progress monitoring.

Step 4: Establish engineering practices

Create lightweight but controlled requirements, design, implementation, testing, and delivery activities.

Step 5: Establish configuration management

Track source code, important documents, releases, and relevant changes.

Step 6: Establish verification and acceptance

Define how the team confirms requirements have been implemented and the customer accepts the product.

Step 7: Collect evidence

Maintain manageable records showing that planned work has been completed.

Step 8: Improve incrementally

Use defects, customer feedback, rework, delivery outcomes, and process observations to improve execution.

Example: Five-person embedded software company

A small team developing a non-safety-critical environmental sensor might start with:

Artifact	Recommended content
Project plan	Scope, schedule, responsibility, risks
Requirements list	Identified and verifiable requirements
Architecture	Main modules, interfaces, data flow
Source repository	Version-controlled implementation
Test report	Requirements-linked results
Release record	Version, changes, acceptance

The aim is disciplined delivery without unnecessary documentation overhead.

When not to rely on ISO/IEC 29110 alone

If the same company begins developing an automotive braking controller or medical infusion device, the engineering approach must also satisfy the applicable safety, regulatory, and customer obligations.

A small company does not receive an exemption from product safety requirements simply because its team is small.

Practical exercise: Implement a lightweight Basic-profile-inspired engineering workflow for a small firmware project and conduct an internal process review.

Tutorial 29 — SPICE for Space: Software Process Assessment and Improvement

Milestones

Simone Chesi – CUS-GNC | LinkedIn

Wenn die Faszination Weltall zum Leben erwacht

12

What is SPICE for Space?

SPICE for Space, also called S4S, is a software process assessment and improvement method developed for the space industry.

It builds on the SPICE process assessment approach and incorporates space-sector engineering and product assurance considerations.

S4S is associated with the European Space Agency (ESA) and the European Cooperation for Space Standardization (ECSS).

ESA describes S4S as a space software process assessment method conformant to ISO/IEC 15504 and aligned with relevant ECSS software engineering and software product assurance process models. ESA Technology

Unlike DO-178C or ISO 26262, SPICE for Space is primarily a process assessment method rather than a complete product safety standard.

Main reference publications

Two important ECSS handbooks are:

• ECSS-Q-HB-80-02 Part 1A — Software Process Assessment and Improvement: Framework
• ECSS-Q-HB-80-02 Part 2A — Software Process Assessment and Improvement: Assessor Instrument

These are listed in the ECSS product assurance handbook collection. European Cooperation for Space Standardization

The S4S method inherits its historical assessment framework from ISO/IEC 15504. Organizations should not assume that an assessment automatically conforms to the successor ISO/IEC 330xx standards without checking the specific assessment model and conformance requirements.

Assessment approach

The S4S framework evaluates two fundamental dimensions:

Dimension	What it evaluates
Process dimension	Which engineering and management processes are performed
Capability dimension	How effectively those processes are performed and managed

Assessment findings can help organizations identify improvement priorities and understand process-related delivery risks.

Step-by-step implementation

Step 1: Define assessment objectives

Determine whether the assessment supports supplier evaluation, internal improvement, project readiness, or organizational capability evaluation.

Step 2: Select assessment scope

Identify the organizational units, projects, and processes to assess.

Step 3: Plan the assessment

Select competent assessors, confirm the assessment method, schedule interviews, and identify required evidence.

Step 4: Collect evidence

Examine plans, requirements, designs, reviews, tests, configuration baselines, change records, and process measurements.

Step 5: Evaluate process performance

Determine whether the process achieves its intended outcomes, supported by objective evidence.

Step 6: Assess capability

Evaluate the relevant process attributes using the applicable assessment model.

Step 7: Identify weaknesses

Document gaps, risks, process inconsistencies, and missing evidence.

Step 8: Establish an improvement program

Prioritize improvements, assign owners, establish measurable objectives, and conduct follow-up assessments.

Example: Satellite software supplier

Consider a supplier developing onboard satellite flight software.

An assessment might identify strong implementation and testing practices but weaknesses in requirements traceability, supplier interfaces, or configuration auditing.

The improvement plan could include:

Finding	Improvement action	Evidence of progress
Missing requirement links	Introduce bidirectional traceability	Reviewed traceability reports
Inconsistent design reviews	Define review criteria	Review records and closed findings
Weak change impact analysis	Establish controlled change process	Approved impact assessments
Limited test evidence	Standardize verification records	Reproducible test reports

Important distinction

SPICE for Space does not replace the applicable ECSS software engineering and product assurance requirements.

It helps assess and improve the capability of processes used to satisfy those requirements.

Practical exercise: Conduct a sample assessment of requirements engineering, configuration management, and software verification for a simulated satellite software project.

4. Complete comparison of all 12 frameworks

A common engineering mistake is choosing a standard based on its popularity rather than its intended application.

The following comparison helps establish where each standard fits.

Standard	Safety focus	Security focus	Lifecycle processes	Process assessment
ISO 26262	Primary	Supporting interface	Yes	No
ISO/SAE 21434	Safety interaction	Primary	Yes	No
IEC 61508	Primary	Limited security interface	Yes	No
DO-178C	Software assurance	Not primary	Yes	No
DO-254	Hardware assurance	Not primary	Yes	No
IEC 62304	Risk-related software lifecycle	Supporting interface	Yes	No
ISO 13485	QMS and regulatory quality	Supporting interface	Organizational	Auditable QMS
EN 50716	Primary	Supporting interface	Yes	No
ISO/IEC/IEEE 12207	General software quality	Can incorporate security processes	Primary	No
ISO/IEC/IEEE 15288	System-level engineering	Can incorporate security processes	Primary	No
ISO/IEC 29110	General engineering	Not primary	Primary	Profile-based evaluation possible
SPICE for Space	Supporting assurance	Not primary	Assesses processes	Primary

The terms “primary” and “supporting” describe the focus of each publication. They do not indicate that compliance with one publication automatically satisfies another.

5. Which standards should you use for your industry?

Choose the engineering domain

Automotive embedded systems

RECOMMENDED STARTING POINT

ISO 26262 + ISO/SAE 21434

Use ISO/IEC/IEEE 15288 and 12207 for complementary lifecycle process structure.

Example application

Electronic braking controller, ADAS or vehicle connectivity

6. A unified engineering workflow

Despite their differences, these standards share recurring engineering disciplines.

The following workflow is a practical integration pattern. It is not a substitute for any standard’s prescribed activities or required ordering.

1

Project scope & applicability

Define the system, intended use, stakeholders and obligations

2

Risk & hazard analysis

Identify hazards, threats, failure conditions and risk controls

3

Requirements engineering

Specify verifiable requirements with clear ownership

4

Architecture & detailed design

Allocate requirements and establish interfaces

5

Implementation & integration

Build and integrate controlled system elements

6

Verification & validation

Demonstrate conformance and intended-use suitability

7

Assurance & release

Review evidence, unresolved issues and approval decisions

8

Operation & maintenance

Monitor, maintain, update and eventually retire the product

These activities may be iterative, concurrent, or revisited following changes. Risk management, configuration control, and assurance evidence collection should continue throughout the lifecycle.

7. Practical implementation using modern engineering tools

Standards generally define expectations and objectives, not universal requirements to purchase particular tools.

An effective implementation combines requirements management, source control, automated verification, controlled workflows, and persistent evidence.

Engineering activity	Example tools
Requirements and traceability	Jama Connect, IBM DOORS Next, Polarion
Modeling	Cameo Systems Modeler, Capella, SysML tools
Project and issue management	Jira, GitLab
Source configuration management	Git, GitHub, GitLab
Static code analysis	Coverity, Polyspace, SonarQube
Software verification	GoogleTest, pytest, CTest, VectorCAST
Embedded hardware testing	Hardware-in-the-loop test benches, CANoe
Cybersecurity analysis	Threat modeling tools, approved security scanners
CI/CD	Jenkins, GitHub Actions, GitLab CI
Evidence management	Controlled document repositories, ALM platforms

Tool suitability depends on the governing standard, project assurance requirements, and intended use.

For example, a commercially available static analysis tool is not automatically qualified for a DO-178C program merely because it generates reports. Tool qualification or confidence arguments may be necessary, depending on its role and the applicable objectives.

Likewise, automated tests passing in GitHub Actions do not automatically establish compliance with ISO 26262 or IEC 62304.

Example project repository structure

The following is a practical template, not a standards-prescribed directory layout.

safety-critical-project/
|
+-- 01-project-management/
|   +-- project-plan.md
|   +-- responsibilities.md
|   +-- compliance-plan.md
|
+-- 02-risk-management/
|   +-- hazards/
|   +-- threat-analysis/
|   +-- risk-register.csv
|
+-- 03-requirements/
|   +-- system-requirements/
|   +-- software-requirements/
|   +-- hardware-requirements/
|   +-- traceability.csv
|
+-- 04-architecture/
|   +-- system-design/
|   +-- software-design/
|   +-- interfaces/
|
+-- 05-implementation/
|   +-- src/
|   +-- include/
|   +-- configuration/
|
+-- 06-verification/
|   +-- test-plans/
|   +-- unit-tests/
|   +-- integration-tests/
|   +-- system-tests/
|   +-- coverage/
|
+-- 07-assurance/
|   +-- reviews/
|   +-- audits/
|   +-- safety-case/
|   +-- release-evidence/
|
+-- 08-change-management/
|   +-- change-requests/
|   +-- impact-assessments/
|   +-- anomaly-reports/
|
+-- .github/
|   +-- workflows/
|
+-- README.mdCode language: PHP (php)

Organizations can keep controlled documents and evidence in an ALM system instead. The critical requirement is managing authoritative versions, records, approvals, and traceability rather than physically storing everything in Git.

8. A practical requirements traceability example

Consider a safety-related embedded temperature controller.

ID	Type	Description	Verification
HAZ-001	Hazard	Excessive temperature may cause damage or harm	Risk analysis
SAF-001	Safety goal	Prevent hazardous overheating	Safety validation
SYS-001	System requirement	Detect defined overtemperature conditions	System test
SW-001	Software requirement	Evaluate temperature input against validated thresholds	Software test
HW-001	Hardware requirement	Provide suitable independent protective mechanism	Hardware verification
TC-001	Test case	Validate threshold detection and fault response	Test report

A mature traceability system should support both forward and backward navigation, identify missing coverage, and show the impact of a changed requirement.

It should also preserve review status and evidence baselines.

9. How to build an internal training program

For teams learning these standards, training should combine concepts, practical exercises, engineering artifacts, and assessment.

The following is a suggested training allocation, not an official course duration or certification prerequisite.

Module	Suggested instructor-led duration	Key practical exercise
ISO 26262	3 days	HARA and safety concept
ISO/SAE 21434	3 days	Automotive TARA
IEC 61508	3 days	Safety-function specification
DO-178C	3 days	Software assurance and coverage
DO-254	2 days	Hardware assurance plan
IEC 62304	2 days	Medical software lifecycle
ISO 13485	2 days	QMS and CAPA
EN 50716	2 days	Railway software safety
ISO/IEC/IEEE 12207	2 days	Software lifecycle mapping
ISO/IEC/IEEE 15288	2 days	Systems V-model
ISO/IEC 29110	1 day	Small-team process tailoring
SPICE for Space	2 days	Sample process assessment
Total	27 days

A foundational learning program can select relevant modules rather than requiring every engineer to complete all 27 days. Specialized roles and assessors will typically need deeper training and practical experience.

10. Self-assessment checklist

Use this interactive checklist for an initial engineering readiness review. It is a generic readiness check, not an official conformity assessment.

Engineering readiness

0 of 12 controls checked

0%

System scope, stakeholders, intended use and applicable standards are identifiedApplicable editions, contracts and regulatory obligations are documentedSafety hazards and cybersecurity threats are analyzed where relevantRequirements are uniquely identified, reviewed and verifiableRequirements are traced to design and verification evidenceHardware, software and system interfaces are controlledVerification and validation activities are planned and performedConfiguration management and change impact analysis are operationalDefects, anomalies and nonconformities are evaluated and resolved appropriatelyAssurance evidence and required independent reviews are availableSupplier responsibilities and delivered evidence are definedMaintenance, monitoring and retirement responsibilities are established

Reset Copy checklist

Completion indicates that a topic has been checked, not that any specific regulatory or certification requirement has been satisfied.

11. Frequently asked questions

Is ISO 26262 the same as Automotive SPICE?

No. ISO 26262 addresses automotive functional safety. Automotive SPICE assesses engineering process capability. Organizations often use both, but they serve different purposes.

Can ISO/SAE 21434 replace ISO 26262?

No. Cybersecurity risk management and functional safety are related, but neither standard comprehensively replaces the other.

Does a SIL 3 certification of one component make the entire system SIL 3?

No. System-level safety integrity depends on the complete safety function, architecture, application conditions, systematic capability, and applicable assessment requirements.

Is DO-178C certification required for every aviation application?

Not every aviation-related application is subject to DO-178C. Applicability depends on the airborne system, its safety role, approval basis, and the accepted means of compliance.

Does IEC 62304 certify a medical device?

No. It establishes software lifecycle requirements. Device approval and market access depend on applicable regulatory frameworks and additional requirements.

Can Agile and DevOps be used in safety-critical development?

Yes, where the processes are tailored appropriately and required objectives, independence, traceability, verification, and assurance evidence are maintained.

Are ISO/IEC/IEEE 12207 and 15288 competitors?

No. They provide complementary software and systems lifecycle process frameworks. Organizations can apply both.

Can a startup developing safety-critical products rely exclusively on ISO/IEC 29110?

No. Team size does not eliminate applicable safety and regulatory obligations.

Is SPICE for Space equivalent to Automotive SPICE?

No. Both draw from process assessment principles, but their domain-specific process models and assessment expectations differ.

12. Official standards and technical references

These organizations provide authoritative publications, standard descriptions, and relevant guidance.

Organization	Reference
ISO	ISO 26262 functional safety
ISO	ISO/SAE 21434 cybersecurity
IEC	IEC 61508 functional safety
FAA	DO-178C recognition guidance
FAA	DO-254 recognition guidance
IEC	IEC 62304 medical software lifecycle
ISO	ISO 13485 quality management
European standards body	EN 50716 railway software
ISO	ISO/IEC/IEEE 12207 software lifecycle
IEEE	ISO/IEC/IEEE 15288 systems lifecycle
ISO	ISO/IEC 29110 series
ECSS / ESA	SPICE for Space assessment handbook

The summaries and examples in this guide are educational. Official standard texts, project-specific tailoring decisions, regulatory obligations, and accepted compliance plans remain authoritative for actual safety-critical development.

Conclusion

Developing safety-critical software requires a different engineering mindset from conventional application development.

Reliable implementation is only one part of the work. Engineering teams must also demonstrate that they understand the system, have evaluated hazards and threats, have converted risk controls into precise requirements, and have verified the resulting design through controlled and repeatable processes.

The most effective approach is to select the relevant domain standard first, integrate complementary systems and software lifecycle processes, and establish traceability and assurance evidence from the beginning of development.

The central principle across all 12 frameworks is simple: safety, security, and quality must be engineered into the product throughout its lifecycle—not inspected into it after development is complete.