The Barr Group’s latest survey queried thousands of embedded programmers and reveals some interesting statistics about safety and security in current development. Here are a few of my observations.
There was no surprise in the programming language category (Fig. 1). C remains the mainstay for embedded developers, with C++ being the only alternative of note. And I suspect a majority of embedded C++ development uses a minimal number of object-oriented programming (OOP) features. That is not necessarily bad, but it would essentially push the C stack even higher.
The reason for the popularity of C is clear given its relative portability and wide availability. There is not a new microcontroller or microprocessor that does not have a C compiler for it that is usually part of a free developer package from the chip vendor. Unfortunately C’s flexibility and dependence on programmers doing the right thing that it also tends to be the most prone to generating lots of bugs that are getting us into trouble as we are inundated by the interconnected Internet of Things (IoT).
I was not surprised to see Ada way down on the list, but it had good company. Many know of my preference for Ada for embedded applications and it is available for microcontrollers like ARM’s Cortex-M. I leave it to authors with more expertise to address Ada’s myths and comparison to C.
I brought up the issue of programming languages first because it ties into their No. 1 finding that safety risks abound (Fig. 2). Injuries can be related to automotive accidents for the growing number of electronics with a car to products that could catch fire. This does not include security-related issues that could indirectly affect safety.
The drill-down (Fig. 3) was for only those involved in projects that could cause injuries. One might expect 100% adherence to best safety practices in design and coding, but it looks like there are still gaps. This could be due to the fact that many safety standards are voluntary.
For the same subset, the amount of system level testing was over 80% but under 60% for regression testing (Fig. 4). The results were much lower for the entire group. That is not surprising given that testing costs time and money. Implementing a system to automate testing is often something overlooked or deemed too expensive for many embedded projects. This tends to be a requirement for application areas that have safety and security critical standards where the added costs are expected. Still, these tend to be in areas like aviation or medical where mandatory standards exist.
Not surprisingly, connectivity is on the rise. The survey shows that over 60% of the current crop of projects will be connected. Over 80% will have a wired connection and almost half will have a wireless connection. Many of the wireless devices will also have a wired connection, hence the overlap, but it is likely that the wireless link will be the primary one.
Another tidbit is that the number of multiple processor designs is significant and increasing. Only 25% of the projects used a single core, with a third having two or three processors. That leaves over 40% using four or more cores.
Given the number of stories about security issues and the aforementioned results, it is surprising that security is not more of a consideration. In fact, almost 40% of the projects did not require security (Fig. 5). There did seem to be interest in having more security, but don’t start celebrating yet.
So what security issues were important? Surprisingly, or not, product tampering topped the list (Fig. 6). A significant number of concerns were vendor-related versus the user of the product. The challenge is interpreting the results since injury or death are unlikely to be concerns for most embedded developers, where they are at the top of the list for areas like medical and aviation. Likewise, there is the question of how much effort and cost will be used to address the various areas. Hopefully, a product’s security support will not be limited to protecting the vendor’s IP.
This brings us back to coding support to address safety and security issues. If you start at the language and coding level, then languages like Ada, tools like static analysis, and automated enforcement of coding standards are what will make a difference. Unfortunately, that is not where things stand now (Fig. 7).
Embedded application development is not getting easier. It is becoming much more difficult and involves many more pieces than in the past. Adding connectivity to a product not only makes it more complex, but it also opens up a host of security issues.
If you have not been implementing coding standards or using tools like static analysis, then it is something that you need to check out. They really do help reduce bugs and that can actually reduce overall development time. I suspect that a suggestion to check out Ada will quickly be discarded out of hand, but I make it anyway.
In the meantime, check out the full survey results on the Barr Group’s site.
Looking for parts? Go to SourceESB.
