NE's embedded software survey shows engineers are getting smarter

Today, writing, debugging and verifying embedded software can consume the lion's share of the development budget, as well as much of the design cycle time. More complex software needs more capable tools, not only to write the code in the first place, but also to make sure it does what the developer intended. And when the software is used in a critical elements of a system, it may well need to be written to a particular standard and tested against it. Then there are operating system issues, as well as security concerns. Looking to explore these issues, New Electronics recently surveyed its readers to find out just what's happening with embedded software development in the UK. With development time apparently one of the major issues, we asked how long your last software development project took to complete. Almost three quarters of respondents to the survey said their project was completed in less than a year. While 35% of respondents said their project took more than a year to complete, 16% of you completed development in less than three months, 21% took three to six months and 28% took six months to a year. But were the projects delivered on time? Yes, came the answer, but it wasn't very convincing. Slightly more than half of engineers (53%) said their project was on time, balanced by 44% of respondents admitting to an overrun. Just 3% said they beat the clock. In years gone by, embedded software developers were often constrained by the amount of memory available for code. Is this still the case? It is, according to our survey: 54% of developers have to fit their code into a given footprint. Did they manage to do so? The response was almost unanimous. Yes. With strict project deadlines, writing code from the blank sheet of paper starting point becomes a challenge. How many of you took advantage of previously written blocks of code in your latest project? The answer was 84%, indicating an increasingly smart approach to writing software. However, reuse of code isn't always as simple as it might seem. If the next project uses a different microcontroller, the code needs to be retargeted. Almost half of those respondents who are reusing code had to retarget it. As many software developers will know, a range of approaches is available. We asked what you use. By far the most popular approach is the use of C/C++, with assembler taking a distant second place. Amongst other techniques being applied are managed code and UML based tools. But there is growing interest in graphical based software design. Both LabVIEW and Matlab/Simulink made a showing in the survey results. And what standards do you write software to comply with? Surprisingly, six out of 10 respondents said 'none'. Of those writing to standards, MISRA C was the most popular, followed by ISO61508, safety integrity level (SIL) and ISO26262. Of those writing to SIL standards, most addressed SIL 2. Of course, there are other standards addressing embedded software development. Several respondents said their projects were written to meet internally developed standards. Instinctively, you might have thought this would have correlated against larger companies, but even those at the small end of the scale had developed in house standards for software. What tools are used in the development process? Almost everyone (97%) uses a compiler, while 88% take advantage of a debugger and 65% use an in circuit emulator or Jtag debugger. Also showing popularity amongst the tools being deployed are static code analysers and high level modelling tools, including state machines and graphical simulators. While some embedded systems require no more than an 8bit microcontroller, those with increased functionality, along with those looking to implement some form of communications, will need the power afforded by a 32bit device. Our survey showed that 48% of you are developing software for 32bit microcontrollers, with 31% working with 16bit parts and 21% using an 8bit device. Looking to the future, the survey found more of you will be designing in 32bit products – two thirds in fact. A quarter of you will use 16bit parts and just 8% will use an 8bit part for future projects. The move to 32bit processors brings with it the opportunity to use multiple core devices, although there is still the opportunity to design multiple processor systems. What are New Electronics' readers doing? We found 73% of respondents are writing software for multiple processor systems, while 39% are targeting a multiple core device. Is this a new development, we asked? Apparently not: 32% of respondents have previously developed software for a multiple core device and 77% of you have written code for multiple processor systems. What kind of operating system does the code run on? Do you use commercially available, open source or proprietary operating systems? Most popular are proprietary OSs, selected by 43% of respondents, with 37% using commercially available OSs and 26% selecting open source OSs. We asked then how many of you have developed a Linux based system, including the various 'flavours'. It turns out that 28% of respondents have used Linux. When those who haven't used Linux before were asked whether they were considering developing a Linux based system, three quarters of them said no. We also wanted to know whether you'd heard about virtualisation – it's a technique that can help with boosting performance, improving safety and security and which can assist in moving to a different platform. More than 60% said they were aware of the approach, but only 20% of respondents have implemented such a system. Will those who haven't implemented virtualisation be doing so in the future? It appears not; 83% of them said no. An increasing number of embedded systems now include internet connectivity. We found that 30% of respondents have provided that functionality in their last design. But was protection designed in? When asked whether there was some form of access control, 60% said yes. And 64% of respondents are considering adding security and access control features to their next project. There's a range of variables to consider when developing embedded software, but which is most important? Most popular was keeping to schedule (39%), with using familiar tools and methods also showing strongly at 29% of respondents. We also asked respondents to write in what mattered to them. Included were some things that all developers will recognise, including 'stop customers changing the specs halfway through' and 'tying down the requirements as early as possible'. But a common theme will resonate with all engineers – our respondents wanted to get it right, keep it simple and to provide a quality product.