5 exercises on safety and compliance terminology: MISRA C, functional safety, IEC 61508, DO-178C, and certified RTOS. Advanced
0 / 26 completed
1 / 26
Your project manager states: "All C code in this safety-critical module must comply with MISRA C — no exceptions without a formal deviation record."
What is MISRA C?
Correct: B.MISRA C (Motor Industry Software Reliability Association C) is a widely adopted coding standard, originally developed for automotive software but now used across aerospace, medical, industrial, and other safety-critical domains. It defines required and advisory rules — for example, banning dynamic memory allocation after initialization, prohibiting direct casts between pointer and integer types, and requiring all switch statements to have a default clause.
Version
Base standard
Common in
MISRA C:2004
C90 / C99
Automotive (legacy projects)
MISRA C:2012
C99 / C11
Automotive, medical, industrial
Deviation record
Documents justified rule violation
Required when a rule cannot be followed
2 / 26
A systems architect explains: "The braking ECU requires functional safety — it must keep the vehicle safe even if a sensor fails or the software encounters an unexpected error."
What does functional safety mean?
Correct: B.Functional safety is about safe behaviour under failure, not just correct behaviour under normal conditions. A functionally safe system detects faults (via hardware diagnostics, watchdogs, cross-checking) and responds in a controlled, predictable safe state — for example, applying maximum braking instead of releasing all brake pressure when a sensor fails. It is formalised by standards such as IEC 61508, ISO 26262, and DO-178C.
Concept
Meaning
Safe state
Controlled condition entered when a fault is detected
Fault tolerance
System continues operating safely despite a fault
Fail-safe
System automatically moves to a safe state on failure
Diagnostic coverage
Fraction of dangerous faults detected by diagnostics
3 / 26
A safety engineer says: "The pump controller must achieve SIL 2 according to IEC 61508 — that drives our entire development and verification process."
What is IEC 61508?
Correct: B.IEC 61508 is the foundational functional safety standard for E/E/PE (electrical, electronic, and programmable electronic) systems. It defines four Safety Integrity Levels — SIL 1 (lowest) to SIL 4 (highest required risk reduction). Derived domain-specific standards include ISO 26262 (automotive), IEC 62061 (machinery), and IEC 62443 (industrial cybersecurity).
SIL
PFH (dangerous failures/hour)
Example application
SIL 1
10⁻⁶ – 10⁻⁵
Industrial conveyor safety stop
SIL 2
10⁻⁷ – 10⁻⁶
Emergency shutdown valve, pump
SIL 3
10⁻⁸ – 10⁻⁷
Burner management, railway signalling
SIL 4
10⁻⁹ – 10⁻⁸
Nuclear reactor protection
4 / 26
The project compliance officer states: "All flight control software must satisfy DO-178C Design Assurance Level A — that's the highest level, for software whose failure could cause a catastrophic aircraft accident."
What is DO-178C?
Correct: B.DO-178C (Software Considerations in Airborne Systems and Equipment Certification) is published by RTCA and recognised by aviation regulators worldwide (FAA, EASA). It defines five Design Assurance Levels based on the severity of the failure condition: DAL A (catastrophic) requires the most rigorous development and verification — including 100% MC/DC structural coverage — while DAL E (no safety effect) requires minimal activity.
DAL
Failure condition
Coverage required
A
Catastrophic
MC/DC (100%)
B
Hazardous
Decision coverage (100%)
C
Major
Statement coverage (100%)
D
Minor
No structural coverage req.
5 / 26
An architect proposes: "We should switch from a community RTOS to a certified RTOS that already has a DO-178C DAL A qualification kit — it significantly reduces our certification effort."
What is a certified RTOS?
Correct: B. A certified RTOS (sometimes called a qualified RTOS or safety RTOS) has been developed under a safety lifecycle process and verified to the degree required by a target standard. The vendor supplies a qualification kit — test suites, coverage reports, tool qualification data, and documentation — as evidence artefacts that regulators accept as part of the system's certification dossier. Examples include INTEGRITY (GHS), LynxOS-178, VxWorks 653, and SafeRTOS.
RTOS
Certification / Standard
Domain
SafeRTOS
IEC 61508 SIL 3, ISO 26262 ASIL D
Industrial, automotive
LynxOS-178
DO-178C DAL A
Avionics
INTEGRITY
DO-178C, IEC 62443
Avionics, defence
6 / 26
Reviewer: 'I'm seeing a lot of implicit conversions here. While it might work, we need to explicitly cast these variables to ensure predictable behavior and avoid potential timing issues within the RTOS scheduler. Can you provide justification for this approach?'
This scenario highlights the importance of understanding how data types are handled in resource-constrained environments like RTOS systems. Implicit conversions can introduce timing dependencies due to unpredictable memory access patterns and scheduler behavior— a critical concern for safety-critical applications where deterministic execution is paramount. Explicit casting provides control over this process, mitigating potential issues and improving predictability.
7 / 26
PR Description:
"Implementing timer interrupt for sensor data acquisition. Utilizing a non-blocking approach to minimize latency and avoid impacting the RTOS scheduler. Performance testing indicates minimal overhead."
This scenario highlights the importance of understanding how interrupt handling interacts with an RTOS scheduler. The developer's phrasing demonstrates awareness of potential latency and scheduling impacts, which is crucial in safety-critical systems where predictable timing is paramount. Option A incorrectly prioritizes readability over real-time concerns; option C describes a problematic practice, and option D suggests inappropriate communication.
8 / 26
During a code review of the engine control unit (ECU) software, a senior developer comments: 'I'm concerned about potential race conditions in this interrupt handler. We need to ensure exclusive access to shared resources – consider using mutexes or semaphores to prevent data corruption.' What is the *primary* reason for this concern and recommendation?
// Potential race condition example
volatile int counter = 0;
void ISR() {
counter++; // Multiple interrupts can increment simultaneously
}
The correct answer highlights the core issue of race conditions. Race conditions arise when multiple tasks or threads access and modify shared resources simultaneously without proper synchronization. The developer's recommendation—using mutexes or semaphores—is precisely to enforce exclusive access to these shared resources, preventing data corruption caused by concurrent modifications. Options A and C misrepresent how volatile variables and performance optimizations relate to concurrency; option D is incorrect because the RTOS does not inherently prevent race conditions without explicit synchronization mechanisms.
9 / 26
Reviewer: 'I'm seeing a lot of implicit conversions here. While it might work, we need to explicitly cast these variables to ensure predictable behavior and avoid potential timing issues within the RTOS scheduler. Can you provide justification for this approach?'
This scenario highlights the importance of understanding how data types are handled in resource-constrained environments like RTOS systems. Implicit conversions can introduce timing dependencies due to unpredictable memory access patterns and scheduler behavior— a critical concern for safety-critical applications where deterministic execution is paramount. Explicit casting provides control over this process, mitigating potential issues and improving predictability.
10 / 26
PR Description:
"Implementing timer interrupt for sensor data acquisition. Utilizing a non-blocking approach to minimize latency and avoid impacting the RTOS scheduler. Performance testing indicates minimal overhead."
This scenario highlights the importance of understanding how interrupt handling interacts with an RTOS scheduler. The developer's phrasing demonstrates awareness of potential latency and scheduling impacts, which is crucial in safety-critical systems where predictable timing is paramount. Option A incorrectly prioritizes readability over real-time concerns; option C describes a problematic practice, and option D suggests inappropriate communication.
11 / 26
During a code review of the engine control unit (ECU) software, a senior developer comments: 'I'm concerned about potential race conditions in this interrupt handler. We need to ensure exclusive access to shared resources – consider using mutexes or semaphores to prevent data corruption.' What is the *primary* reason for this concern and recommendation?
// Potential race condition example
volatile int counter = 0;
void ISR() {
counter++; // Multiple interrupts can increment simultaneously
}
The correct answer highlights the core issue of race conditions. Race conditions arise when multiple tasks or threads access and modify shared resources simultaneously without proper synchronization. The developer's recommendation—using mutexes or semaphores—is precisely to enforce exclusive access to these shared resources, preventing data corruption caused by concurrent modifications. Options A and C misrepresent how volatile variables and performance optimizations relate to concurrency; option D is incorrect because the RTOS does not inherently prevent race conditions without explicit synchronization mechanisms.
12 / 26
Reviewer: 'I'm seeing a lot of implicit conversions here. While it might work, we need to explicitly cast these variables to ensure predictable behavior and avoid potential timing issues within the RTOS scheduler. Can you provide justification for this approach?'
This scenario highlights the importance of understanding how data types are handled in resource-constrained environments like RTOS systems. Implicit conversions can introduce timing dependencies due to unpredictable memory access patterns and scheduler behavior— a critical concern for safety-critical applications where deterministic execution is paramount. Explicit casting provides control over this process, mitigating potential issues and improving predictability.
13 / 26
PR Description:
"Implementing timer interrupt for sensor data acquisition. Utilizing a non-blocking approach to minimize latency and avoid impacting the RTOS scheduler. Performance testing indicates minimal overhead."
This scenario highlights the importance of understanding how interrupt handling interacts with an RTOS scheduler. The developer's phrasing demonstrates awareness of potential latency and scheduling impacts, which is crucial in safety-critical systems where predictable timing is paramount. Option A incorrectly prioritizes readability over real-time concerns; option C describes a problematic practice, and option D suggests inappropriate communication.
14 / 26
During a code review of the engine control unit (ECU) software, a senior developer comments: 'I'm concerned about potential race conditions in this interrupt handler. We need to ensure exclusive access to shared resources – consider using mutexes or semaphores to prevent data corruption.' What is the *primary* reason for this concern and recommendation?
// Potential race condition example
volatile int counter = 0;
void ISR() {
counter++; // Multiple interrupts can increment simultaneously
}
The correct answer highlights the core issue of race conditions. Race conditions arise when multiple tasks or threads access and modify shared resources simultaneously without proper synchronization. The developer's recommendation—using mutexes or semaphores—is precisely to enforce exclusive access to these shared resources, preventing data corruption caused by concurrent modifications. Options A and C misrepresent how volatile variables and performance optimizations relate to concurrency; option D is incorrect because the RTOS does not inherently prevent race conditions without explicit synchronization mechanisms.
15 / 26
Reviewer: 'I'm seeing a lot of implicit conversions here. While it might work, we need to explicitly cast these variables to ensure predictable behavior and avoid potential timing issues within the RTOS scheduler. Can you provide justification for this approach?'
This scenario highlights the importance of understanding how data types are handled in resource-constrained environments like RTOS systems. Implicit conversions can introduce timing dependencies due to unpredictable memory access patterns and scheduler behavior— a critical concern for safety-critical applications where deterministic execution is paramount. Explicit casting provides control over this process, mitigating potential issues and improving predictability.
16 / 26
PR Description:
"Implementing timer interrupt for sensor data acquisition. Utilizing a non-blocking approach to minimize latency and avoid impacting the RTOS scheduler. Performance testing indicates minimal overhead."
This scenario highlights the importance of understanding how interrupt handling interacts with an RTOS scheduler. The developer's phrasing demonstrates awareness of potential latency and scheduling impacts, which is crucial in safety-critical systems where predictable timing is paramount. Option A incorrectly prioritizes readability over real-time concerns; option C describes a problematic practice, and option D suggests inappropriate communication.
17 / 26
During a code review of the engine control unit (ECU) software, a senior developer comments: 'I'm concerned about potential race conditions in this interrupt handler. We need to ensure exclusive access to shared resources – consider using mutexes or semaphores to prevent data corruption.' What is the *primary* reason for this concern and recommendation?
// Potential race condition example
volatile int counter = 0;
void ISR() {
counter++; // Multiple interrupts can increment simultaneously
}
The correct answer highlights the core issue of race conditions. Race conditions arise when multiple tasks or threads access and modify shared resources simultaneously without proper synchronization. The developer's recommendation—using mutexes or semaphores—is precisely to enforce exclusive access to these shared resources, preventing data corruption caused by concurrent modifications. Options A and C misrepresent how volatile variables and performance optimizations relate to concurrency; option D is incorrect because the RTOS does not inherently prevent race conditions without explicit synchronization mechanisms.
18 / 26
Scenario: During a standup meeting, a developer explains their progress. Developer: 'I'm using an RTOS task to handle sensor data acquisition and then sending that data over a UART.'
Using an RTOS task to handle sensor data acquisition and sending the data over UART is a standard practice. This demonstrates understanding of real-time scheduling and communication protocols within an embedded system.
Options B, C, and D are incorrect as they misrepresent best practices or introduce unnecessary constraints.
19 / 26
Scenario: A project manager asks for clarification on a technical document. Project Manager: 'Can you explain the concept of 'deterministic execution' in relation to this RTOS? It's crucial for ensuring our system meets its safety requirements.'
Deterministic execution is a core concept in real-time systems and safety-critical applications. It describes the ability of the system to consistently produce the same output given the same input over time – this predictability is vital for meeting stringent timing requirements and ensuring reliable operation.
Option A misrepresents the definition, while options B, C, and D are incorrect.
20 / 26
Scenario: A developer is writing a code review comment. Developer: 'I noticed you're using a priority-based preemptive scheduling algorithm here. While it's common, consider the potential for jitter and its impact on timing constraints within this safety-critical system.'
Priority-based preemptive scheduling is a frequently used algorithm, but it's important to acknowledge its potential downsides. Jitter (variations in execution time) can cause timing violations and impact the system's ability to meet deadlines—a serious concern in safety-critical applications.
Options A, C, and D are all incorrect statements.
21 / 26
Scenario: An experienced developer is mentoring a junior developer. Senior Developer: 'When designing interrupt handlers in an RTOS, it's crucial to avoid blocking operations and use techniques like non-blocking I/O to minimize latency and prevent impacting the RTOS scheduler.'
Blocking operations within interrupt handlers can severely impact system responsiveness and introduce timing issues. Non-blocking I/O techniques allow the handler to complete its task quickly without preventing the RTOS from scheduling other tasks – critical for maintaining predictable performance in a safety-critical environment.
Options A, B, C, and D are all incorrect.
22 / 26
Sarah (Senior Embedded Systems Engineer) sends this message to the team channel: 'Just finished reviewing the new watchdog timer implementation. Seems robust, but I'm still concerned about potential starvation if a high-priority task consistently blocks the watchdog. Any thoughts?'
Which of the following best describes Sarah's concern?
Sarah's concern centers on 'starvation,' which in this context refers to a lower-priority task being perpetually blocked by a higher-priority one. This is a key issue in RTOS design, especially when dealing with interrupt handlers or periodic tasks, where improper prioritization can lead to indefinite blocking and system instability. The other options misinterpret the term's meaning within an embedded systems/RTOS environment.
23 / 26
Reviewer: 'I'm seeing a lot of frequent polling in this interrupt handler. While it might seem efficient initially, continuous polling can introduce significant latency and negatively impact the RTOS scheduler's determinism. Could we explore using an event-driven approach instead?'
What is the reviewer primarily highlighting?
The reviewer's comment focuses on the detrimental impact of frequent polling – continuous CPU access – on the RTOS scheduler. Polling introduces latency and disrupts the scheduler's ability to guarantee deterministic execution times for tasks, which is critical in safety-critical systems. The other options represent related but distinct concerns.
24 / 26
PR Description:
'Implemented a mutex to protect shared data access between two RTOS tasks. This ensures mutual exclusion and prevents race conditions during data updates. The mutex is implemented with a priority inheritance protocol to minimize priority inversion issues.'
What does 'priority inheritance protocol' primarily aim to address?
Priority inheritance protocol is designed to mitigate priority inversion – a situation where a high-priority task is blocked by a lower-priority one while holding a resource. By temporarily increasing the priority of the lower-priority task, the protocol allows it to execute and release the resource before the higher-priority task resumes, preventing indefinite blocking.
25 / 26
"I'm working on implementing a real-time clock (RTC) driver using an RTOS timer. I've configured the timer to trigger every second and update a shared variable representing the current time. I'm mindful of potential race conditions when updating this variable, but haven't implemented explicit locking yet."
The key concern highlighted here is potential race conditions when updating the shared variable. While latency optimization and accuracy are important considerations, addressing the immediate risk of data corruption through explicit locking (e.g., a mutex) is paramount in a safety-critical system where incorrect time values could have serious consequences.
26 / 26
A project lead asks: 'We're transitioning to a more deterministic RTOS. What does it *really* mean in terms of our system's behaviour?'. Which statement best explains the core concept?
'Deterministic execution' doesn't guarantee flawless code or absolute zero latency. Instead, it implies that the system will consistently produce predictable and repeatable results given identical inputs and conditions. This predictability is crucial for safety-critical systems where timing variations can lead to unpredictable behaviour.
What does the "Safety-Critical Systems Vocabulary — Embedded & RTOS Language Exercises" exercise cover?
Practice English vocabulary for safety-critical embedded development: MISRA C, functional safety, IEC 61508, DO-178C, and certified RTOS terminology used in regulated engineering domains.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Safety-Critical Systems Vocabulary — Embedded & RTOS Language Exercises"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Embedded & RTOS exercises?
Browse the full Embedded & RTOS hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.