safety

An introduction to embedded control systems along with a practical example on the differences between open and closed loop systems.

Learn practical and easy-to-apply software process improvements that even the smallest design teams can use to make firmware easier to code, debug and test, with a tools cost of less than $600.

On May 3, 2017, Barr Group CTO and software expert Michael Barr delivered this keynote about the safety and security of Internet of Things devices at the Embedded Systems Conference in Boston.

If you've got a lot of real-time tasks and tight deadlines, what's the best way to prioritize them? Rate Monotonic Algorithm provides the optimal technique.

In a recent DDoS attack, devices such as webcams and DVRs were used to launch an attack on domain service provider, Dyn. The enormity of this event brings to light the importance of securing all devices capable of connecting to the Internet.

The safety and security of every embedded system is dependent upon proper operation of the stack (or stacks, if there are multiple). If a stack overflow occurs, a major or minor malfunction is very likely to follow. Despite this, the stack in the majority of embedded systems is sized based on nothing more than a hunch. As well, run-time stack monitoring is too seldom used.

Too often engineers give up trying to discover the cause of infrequent anomalies--because they can't be easily reproduced in the lab--dismissing them as "user errors" or "glitches." Yet these ghosts in the machine live on. So here's a guide to the most frequent root causes of difficult-to-reproduce firmware bugs.

Too often engineers give up trying to discover the cause of infrequent anomalies--because they can't be easily reproduced in the lab--dismissing them as "user errors" or "glitches." Yet these ghosts in the machine live on. So here's a guide to the most frequent root causes of difficult-to-reproduce firmware bugs.

Whether you're using only static memory, a simple stack, or dynamic allocation on a heap, you have to proceed cautiously. Embedded programmers can't afford to ignore the risks inherent in memory utilization.

Unexpected power loss and software bugs can undermine the reliability of non-volatile data. Fortunately, there are various ways to make non-volatile data resilient to such corruption.

Product usability problems require the engineer to take off his engineering hat and think more like a user.

Proper timing in user interfaces often has more to do with the user's perception than with the actual passage of time.

Understanding software and hardware bugs in other embedded systems can help you identify, diagnose, and fix bugs in your own.

The placement of knobs, buttons, and switches is as essential as the firmware to making a usable embedded system.

State machines are perhaps the most effective method for developing robust event-driven code for embedded systems.

The formalism of Hierarchical State Machines (aka statecharts) makes the state machine approach truly applicable to real-life embedded systems.

Rethinking basic programming techniques can avoid many of the problems that heap-based memory management poses for embedded real-time system designs.

In this first installment of a series of articles on the proper use of a real-time operating system (RTOS), we examine the important differences between a mutex and a semaphore.

A C coding standard can help keep bugs out of embedded software by leveraging common language features and development tools.

This second article on enforceable coding standards for embedded systems adds a set of additional bug-killing rules for using certain C keywords and naming global variables.

An object-oriented framework can be used to create safe, testable and tunable motion control systems.

Barr Group's 2016 Embedded Systems Safety & Security Survey had participation from more than 2,500 embedded systems design engineers and revealed a number of interesting trends in the embedded industry.

It’s a fact: When you create code, you create bugs. Listen in as we present the finer points of Test-Driven Development (TDD) - a game-changing approach to embedded software development that can greatly reduce bugs early in the development process. TDD is not a debugging technique but rather an approach to proactively preventing defects.

As Internet connectivity advances, the transportation, automotive, medical device, smart grid and other industry sectors have become more dependent on embedded software. But is software reliable?

As if debugging traditional PC/server software or even smartphone apps wasn't hard enough, debugging embedded software adds significant challenges.

A number of embedded systems, such as medical devices and printers, feature replaceable components designed to be installed new, consumed through one or more cycles of product use, and ultimately disposed.

What's the difference between a mutex and a semaphore? Misuse of these two distinct types of synchronization primitives can lead to difficult to debug defects with potentially severe consequences in safety-critical devices.

One of the biggest challenges when architecting an embedded system is partitioning the design into its hardware and software components, which must typically be decided early in the design of a product.

Welcome to the 21st century, where every device has at least one processor. But don't take for granted that these devices will do their intended jobs tirelessly and correctly, day in and day out, without fail.

To increase security and keep bugs out of medical devices and other safety-critical embedded systems, add these 10 bug-killing rules to your embedded C coding standard.

As embedded software's size and complexity continue to rapidly progress, user safety increasingly relies upon safe and reliable firmware implementations. Barr Group co-founder and CTO Michael Barr presents an engaging discussion of the past, present, and future of embedded software safety. 

Examining the structure of the ANSI and ISO usability standards is the first step to developing medical devices that protect users from accidents.

Every commercial RTOS employs a priority-based preemptive scheduler. This despite the fact that real-time systems vary in their requirements and real-time scheduling doesn't have to be so uniform. Multitasking and meeting deadlines is certainly not a one-size-fits-all problem.

With thoughtful design, user interfaces for embedded systems can avoid some user errors altogether and helpfully guide the user through the rest.

For embedded software developers, the most significant improvements to the C programming language made in the ISO C99 standard update are in the new <stdint.h> header file. Learn the typedef names for the new fixed width integer data types, to make hardware interfacing in C easier. 

Controller Area Network (CAN) is the most widely-used automotive bus architecture. Here are some reasons why.

At peak, some automobiles contained up to three miles of cabling. To reduce the cost and weight of wiring and still allow ECUs to become more intelligent, new methods had to be found to reduce the amount of wiring. The CAN bus has since found application in other industries as well.

In the market for a real-time operating system (RTOS)? This article provides an overview of RTOSes and how you can select the best one for your project.

In 1998, the UK's Motor Industry Software Reliability Association established a set of 127 guidelines for the use of C in safety-critical systems. Here's a look at the rules, what they mean, and how they can work for you.

Language specifications, including those for C and C++, are often loosely written. A static analysis tool called lint can help you find dangerous and non-portable constructs in your code before your compiler turns them into run-time bugs.

When tasks share resources, as they often do/must, strange things can and will happen. Priority inversions can be particularly difficult to anticipate. A basic understanding of the problem is key.

Memory leaks can be particularly risky for long-running embedded systems. Here are some tools to identify, track, and analyze memory leaks in embedded C and C++ programs.

For those embedded systems that can't be constantly watched by a human, watchdog timers may be the solution.

Most embedded systems need to be self-reliant. It's not usually possible to wait for someone to reboot them if the software hangs. Some embedded designs, such as space probes, are simply not accessible to human operators. If their software ever hangs, such systems are permanently disabled. In other cases, the speed with which a human operator might reset the system would be too slow to meet the uptime requirements of the product.

The proper use of C's volatile keyword is poorly understood by many programmers. This article will teach you the proper way to do it.

Embedded systems programmers often value the assert() macro. This article explores the underlying definition of this handy macro, to show you how to roll your own.

The assert() macro is one of those simple tools that would not seem to merit an entire article, but I have come across an alarming number of engineers who have not heard of it or do not use it.

When it comes to safety-critical applications, sometimes you have to protect users from the software. And sometimes you have to protect users from themselves.

To keep a watchdog timer from resetting your system, you've got to kick it regularly. But that's not all there is to watchdog science. We will examine the use and testing of a watchdog, as well as the integration of a watchdog into a multitasking environment.

If ever there was a piece of embedded software ripe for reuse it's the memory test. This article shows how to test for the most common memory problems with a set of three efficient, portable, public-domain memory test functions.

CRCs are among the best checksums available to detect and/or correct errors in communications transmissions. This article shows how to implement an efficient CRC in C or C++.

Many common types of data transmission errors cannot be detected by additive checksums. This article describes a stronger type of checksum known as a CRC.

What if data is lost or corrupted in transit? Communication protocols usually attempt to detect such errors automatically. To do that they use checksums.

The information that a user gets from a life-critical system may spell the difference between a slight mishap and a serious accident. This article addresses the issue of safety in the design of a user interface.