The three laws of safe embedded systems
This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.
Developing software for a safety-related embedded system for the first time
I spend most of my working life with organisations that develop software for high-reliability, real-time embedded systems. Some of these systems are created in compliance with IEC 61508, ISO 26262, DO-178C or similar international standards.
When working with organisations that are developing software for their first safety-related design, I’m often asked to identify the key issues that distinguish this process from the techniques used to develop “ordinary” embedded software.
...“Smarter” cars, unintended acceleration – and unintended consequences
In this article, I consider some recent press reports relating to embedded software in the automotive sector.
In The Times newspaper (London, 2015-10-16) the imminent arrival of Tesla cars that “use autopilot technology to park themselves and change lane without intervention from the driver” was noted.
By most definitions, the Tesla design incorporates what is sometimes called “Artificial Intelligence” (AI).Others might label it a “Smart” (or at least “Smarter”)...
Important Programming Concepts (Even on Embedded Systems) Part V: State Machines
Other articles in this series:
- Part I: Idempotence
- Part II: Immutability
- Part III: Volatility
- Part IV: Singletons
- Part VI: Abstraction
Oh, hell, this article just had to be about state machines, didn’t it? State machines! Those damned little circles and arrows and q’s.
Yeah, I know you don’t like them. They bring back bad memories from University, those Mealy and Moore machines with their state transition tables, the ones you had to write up...
Important Programming Concepts (Even on Embedded Systems) Part IV: Singletons
Other articles in this series:
- Part I: Idempotence
- Part II: Immutability
- Part III: Volatility
- Part V: State Machines
- Part VI: Abstraction
Today’s topic is the singleton. This article is unique (pun intended) in that unlike the others in this series, I tried to figure out a word to use that would be a positive concept to encourage, as an alternative to singletons, but
The CRC Wild Goose Chase: PPP Does What?!?!?!
I got a bad feeling yesterday when I had to include reference information about a 16-bit CRC in a serial protocol document I was writing. And I knew it wasn’t going to end well.
The last time I looked into CRC algorithms was about five years ago. And the time before that… sometime back in 2004 or 2005? It seems like it comes up periodically, like the seventeen-year locust or sunspots or El Niño,...
Important Programming Concepts (Even on Embedded Systems) Part III: Volatility
1vol·a·tile adjective \ˈvä-lə-təl, especially British -ˌtī(-ə)l\ : likely to change in a very sudden or extreme way : having or showing extreme or sudden changes of emotion : likely to become dangerous or out of control
— Merriam-Webster Online Dictionary
Other articles in this series:
Important Programming Concepts (Even on Embedded Systems) Part II: Immutability
Other articles in this series:
- Part I: Idempotence
- Part III: Volatility
- Part IV: Singletons
- Part V: State Machines
- Part VI: Abstraction
This article will discuss immutability, and some of its variations in the topic of functional programming.
There are a whole series of benefits to using program variables that… well, that aren’t actually variable, but instead are immutable. The impact of...
Important Programming Concepts (Even on Embedded Systems) Part I: Idempotence
There are literally hundreds, if not thousands, of subtle concepts that contribute to high quality software design. Many of them are well-known, and can be found in books or the Internet. I’m going to highlight a few of the ones I think are important and often overlooked.
But first let’s start with a short diversion. I’m going to make a bold statement: unless you’re a novice, there’s at least one thing in computer programming about which you’ve picked up...
Practical protection against dust and water (i.e. IP protection)
Recently, I was faced with a challenge to provide IP65 compliance in a product that had to have humidity and pressure sensors on it. The tricky part was to keep the cost of the unit under $15 while meeting this requirement.
Under normal circumstances, one can put all the electronics within an IP65 enclosure that is affordable and readily available off-the-shelf most of the time such as the ones shown in this link. However, given the humidity and the pressure sensor need to be exposed to...
Data Validity in Embedded Systems
If you take a high-level view of software systems you might say that the overall goal of software is to generate outputs from inputs. It’s a gross simplification of a nuanced and complex field but the truth of the statement is unarguable: data goes in, is manipulated and then is spat out again.That’s what software does. The simplicity of the statement contributes to the joy of Computer Science majors who take an abstract view of everything from software to love but infuriates...
Definite Article: Notes on Traceability
Electronic component distibutor Digi-Key recently announced part tracing for surface-mount components purchased in cut-tape form. This is a big deal, and it’s a feature that is a good example of traceability. Some thing or process that has traceability basically just means that it’s possible to determine an object’s history or provenance: where it came from and what has happened to it since its creation. There are a...
Efficiency Through the Looking-Glass
If you've ever designed or purchased a power supply, chances are you have had to work with efficiency calculations. I can remember in my beginning electronic circuits course in college, in the last lecture when the professor was talking about switching power converters, and saying how all of a sudden you could take a linear regulator that was 40% efficient and turn it into a switching regulator that was 80% efficient. I think that was the nail in the coffin for any plans I had to pursue a...
A design non-methodology
Although writing an RTOS or kernel may be an interesting project, it is unlikely to be a wise course of action.
“Smarter” cars, unintended acceleration – and unintended consequences
In this article, I consider some recent press reports relating to embedded software in the automotive sector.
In The Times newspaper (London, 2015-10-16) the imminent arrival of Tesla cars that “use autopilot technology to park themselves and change lane without intervention from the driver” was noted.
By most definitions, the Tesla design incorporates what is sometimes called “Artificial Intelligence” (AI).Others might label it a “Smart” (or at least “Smarter”)...
Core competencies
Creating software from scratch is attractive, as the developer has total control. However, this is rarely economic or even possible with complex systems and tight deadlines.
Embedded Programming Video Course Shows How OOP Works Under the Hood
If you'd like to understand how Object-Oriented Programming (OOP) really works under the hood, here is a free video course for you:
OOP part-1: Encapsulation: This first lesson on Object-Oriented Programming (OOP) introduces the concept of Encapsulation, which is the ability to package data and functions together into classes. You'll see how you can emulate Encapsulation in C, what kind of code is generated, and how to debug such code. Next, you will translate the C design into C++ using...
Review: Prototype to Product
Prototype to Product: A Practical Guide for Getting to Market, by Alan Cohen, is a must-read for anyone involved in product development, whether in a technical, management, or executive role.
I was reminded of it by Cohen's recent episode on Embedded.fm, 388: Brains Generate EMF, which is worth listening to a couple times through, especially if you're interested in medical device development. And in fact his first episode there,
Software is free and can right any wrong
Software changes are so much easier than hardware modifications, so the temptation is always to take this approach to fixing bugs. This may not always be a good idea.
Coding Step 4 - Design
Articles in this series:
- Coding Step 0 - Development Environments
- Coding Step 1 - Hello World and Makefiles
- Coding Step 2 - Source Control
- Coding Step 3 - High-Level Requirements
- Coding Step 4 - Design
The last article in this series discussed how to write functional high-level requirements: specifications for what your software is supposed to do. Software design is the other side of the coin....
Data Validity in Embedded Systems
If you take a high-level view of software systems you might say that the overall goal of software is to generate outputs from inputs. It’s a gross simplification of a nuanced and complex field but the truth of the statement is unarguable: data goes in, is manipulated and then is spat out again.That’s what software does. The simplicity of the statement contributes to the joy of Computer Science majors who take an abstract view of everything from software to love but infuriates...
More than just a pretty face - a good UI is essential
A user interface can make or break a device - determining its success in the marketplace. With careful design, the UI can make the product compelling and result in a high level of satisfaction from new and experienced users.
Unmanned Ground Vehicles - Design Considerations for Snow and Cold Environments
It's that time of year when the white stuff falls from the sky across the US, and with it comes lower temperatures. These conditions must be taken into consideration when designing a vehicle for outdoor use.
A few definitions from wikipedia:
Flurry: light, brief snowfall
Snow shower: intermittent snowfall
Light snow: over 1km visibility
Moderate snow: 0.5 to 1km visibility
Heavy snow: less than 0.5km visibility
Blizzard: lasts 3 hours or longer, sustained wind to 35mph, visibility...
“Smarter” cars, unintended acceleration – and unintended consequences
In this article, I consider some recent press reports relating to embedded software in the automotive sector.
In The Times newspaper (London, 2015-10-16) the imminent arrival of Tesla cars that “use autopilot technology to park themselves and change lane without intervention from the driver” was noted.
By most definitions, the Tesla design incorporates what is sometimes called “Artificial Intelligence” (AI).Others might label it a “Smart” (or at least “Smarter”)...
3 Tips for Developing Embedded Systems with AI
Explore how to leverage AI in developing embedded systems with three practical tips, learn why documenting your workflows, supercharging testing and debugging, and adopting AI-assisted code generation can save time, reduce errors, and boost performance in your projects, and discover actionable insights to streamline development in resource-constrained environments, this blog explains how to prepare for AI integration while keeping the expertise of experienced engineers intact, offering real-world examples that show how even incremental AI adoption can revolutionize your development process, whether you’re new to AI or seeking to enhance existing practices, these strategies provide a clear roadmap to build smarter, more efficient embedded systems using AI.
Stand-by or boot-up
Many factors affect the usability of devices - a key one is how long it takes to start up.
Autonomous vehicle - design questions to ponder
When designing an autonomous or remotely-controlled vehicle, there are a few factors to take into consideration. Three of these are purpose, environment, and terrain.
What is the purpose of the vehicle?
Will it be used in an industrial setting with people moving around it that it must not run over?
Will it be used in a hazardous environment, like Fukushima or Chernobyl, where it would be exposed to high levels of radiation and must be cleaned or left behind? If it must be left behind, any...
Software is free and can right any wrong
Software changes are so much easier than hardware modifications, so the temptation is always to take this approach to fixing bugs. This may not always be a good idea.
A design non-methodology
Although writing an RTOS or kernel may be an interesting project, it is unlikely to be a wise course of action.
Review: Prototype to Product
Prototype to Product: A Practical Guide for Getting to Market, by Alan Cohen, is a must-read for anyone involved in product development, whether in a technical, management, or executive role.
I was reminded of it by Cohen's recent episode on Embedded.fm, 388: Brains Generate EMF, which is worth listening to a couple times through, especially if you're interested in medical device development. And in fact his first episode there,
