5 Myths About Embedded Systems Development

5 Myths About Embedded Systems Development

Embedded systems are everywhere. For example, our house is full of embedded systems: a washing machine and coffee maker, TV with remote control, electric oven and refrigerator, burglar alarm, stereo and DVD player, wireless “smart home” system.

A car has about 30-40 embedded systems on board. They make a car safer, cost-effective, provide ease of operation and comfort of movement. The fuel injection system, braking system, transmission control system, dashboard devices, central locking and audio system – these all are automotive embedded systems.

They heat or cool car seats, turn mirrors, rotate lights, control the movement of the wipers and doors glasses. In some vehicle models, they can even measure the tire pressure, show the route to the destination point and determine if the driver is tired or not.

Let us also think about the areas of our life in which embedded systems play a key role. Military security systems and government management systems are based on a set of high-performance embedded systems. Embedded systems also control different processes at the space stations and satellites. Any modern machine tool and measuring device – it is also an embedded system.

Many complex medical diagnostic systems are using embedded systems for analysis, results processing, etc. In other words, the embedded system – it is a small computer, that is integrated into the device which it controls.

Despite all the clear benefits of such systems, there are several myths users connect with embedded systems development. These myths suggest that embedded systems are inconvenient and inapplicable for the general use. So let’s take a closer look at each of them and try to figure out whether they correspond to reality or not.

Myth 1. It is very difficult to change the embedded system configuration.

Honestly, after the embedded system has been installed, changing of its configuration – both hardware and software – is quite a challenge. But if the system will be originally programmed to be able to support configuration and different settings, it will greatly simplify software updating processes in the future. Consequently, thorough analysis of the client’s requirements must precede the programming and development process.

These requirements are then converted into a detailed description of the technical characteristics of the future device. Specifications must contain a complete description of the device operation modes including a reaction for each input signal, data, and error processing algorithms. All items that describe the technical characteristics of the device, should be discussed together with the client.

Clear program documentation can also help to accelerate the introduction of the software changes. Many believe that embedded system design and development documentation – is a number of short comments for a working version of the program. However, good documentation of the program is as important as the software itself.

Myth 2. Embedded system can not be scaled.

Yes, one can not scale small embedded systems to a higher level without complete replacing of the core architecture. The main advantage of small systems is that they usually don’t demand a large initial investment, have low risks and are rapidly implemented.

However, it’s very difficult to improve these projects, and it is almost impossible to scale. The insurmountable limitation here is the base software platform. Otherwise, larger projects have the rich functionality and are designed with the possibility to scale.

So, is it possible to start with a small configuration and scale it to a desired size, if necessary? Yes, but it requires a special level of architecture that provides comprehensive scalability, automation, and informatization.

Today there are embedded systems companies that provide an effective software architecture solutions with the help of which embedded systems can be significantly scaled in all directions. Such approach makes it possible to gradually develop software solutions in line with business needs without changing the core technology. Therefore, the most important step in the development of embedded systems is the right choice of a software platform.

Myth 3. There are hardware limitations due to the memory restrictions.

This is a popular myth. What is it based on? Developers of embedded systems have been limited by the volume of the processor’s memory for a long time. While developing embedded systems the idea of minimizing storage costs has been dominated. Now multi-core technologies came to shake things up.

Multi-core processors have already occupied a central place in the product lines of the leading suppliers of semiconductor products with chips that have from two to eight cores. Compared with conventional integrated circuits, they provide greater computing power thanks to a parallel processing.

Multi-core processors offer better system organization, as well as work at lower clock speeds. The main difficulty with multi-core systems is that the developers need to go from a serial performance model to a parallel performance model, where all the processes are carried out simultaneously.

The higher level of parallelism, developers reach, the better the performance of multi-core systems they get. The effective use of multi-core technology significantly improves the performance and scalability of the network equipment, control systems, video game platforms and a variety of other embedded applications.

Myth 4. Only assembler can be used for embedded system software development.

Many developers of embedded systems use for the devices programming only assembly language.Yes, a well-written program in assembly language runs faster and uses less memory space than the program written in a high-level language. This is important aspect at a relatively low speed and limited memory.

Plus assembly language provides developers with direct access to any hardware devices. However, at the same time, a programmer should thoroughly understand the algorithms of code conversion and have a very good knowledge of hardware features and features of microcontroller’s command system.

But here, arises a risk of codes incompatibility. In other words, when we will need to use another type of device we will spend a lot of time trying to adapt our program to another system assembly instructions. On the other hand, high-level languages allow creating a source code, which can be portable. On the basis of this source code, executable machine code is generated.

Programs in high level language have a higher level of abstraction. Therefore, the programmer can complete the project in less time comparing to the same project in assembly language. By the way, if the same previously developed code will be used for future projects, it will significantly increase programming efficiency.

The best time saving result can be achieved if we will use both high-level language and assembler for the project development. The main part of the application will be written in C, and time-critical algorithm fragments – in assembler.

Myth 5. Embedded systems are relatively isolated and therefore are protected from a wide range of threats.

Not so long time ago, the issue of a system security wasn’t a crucial question for the developers. However, the age of connected devices, underscore the need to think about these issues more serious. Modern devices are often connected to corporate networks, clouds, or directly to the Internet. On the one hand, it increases the functionality and ease of use, and on the other, it makes the device more vulnerable to external influences.

The most effective way to ensure a reasonable balance between functionality and security devices is to determine the security requirements before the software development.

This should be done in the context of the overall system and operating environment including a network environment. Moreover, the earlier these processes will start, the more effective they will work. Embedded device must be designed in the way to make it impossible for a potential attacker to hack the system. At the same time security system must be able to cope with a wide range of threats – from network attacks to a physical threats.

CATEGORY: Press-Releases

    Popular posts

    Related posts