Designing electronic systems engineer must consider a multitude of factors that will influence the overall safety of the device.

The success of a properly functioning device is the result of the efforts of multiple design departments.

When discussing safety, this area is most commonly associated with the work of programmers. This connection is entirely justified, as the correctness of algorithms, response to potential emergency situations, communication with users, and many other aspects depend on their work.

Safety isn’t just about ensuring that the program’s algorithms function correctly to make the device operate. It also involves ensuring that any unexpected situations do not adversely affect the device’s operation. Additionally, it means guaranteeing that the device has no detrimental impact on the external environment and that it operates reliably under various physical conditions.

In this article, I will outline the areas where security considerations are crucial. We will discuss the following domains:

• Software
• Hardware
• Power Supply
• Directives and Standards

Software is mentioned first, because it is an area of design where a lot of work can be done to ensure safety.

It’s no surprise that the way code is written has a significant impact on the correct functioning of the device. Chaotically written code is prone to mistakes and writing errors. Therefore, it’s essential to standardize the naming of variables, functions, methods, classes and other application elements. Incomprehensible code is challenging to analyze and can lead to errors during development.

Neglecting the cleanliness and clarity of the code can cause problems from a development and maintenance perspective. In the event of a failure, the absence of the code’s author can become very challenging. That’s why it’s crucial for every program to be documented and written in a clear, readable manner for other programmers. There are several books on how to write such programs that are worth reading, so I encourage you to read them to avoid all the potencial problems.

In addition to readable code, the programmer should ensure that there is no erroneous memory access. An example of this, is accessing an array using a variable containing a negative value.
Of course, during compilation, no error will be generated and there should be no warning. In such case, reading from the array might yield some specific result, but it can also trigger a HARD FAULT exception, causing the program to stop functioning.

In critical situations, just before using an array [x], it is imperative to check the value of x. If x has the correct value, the operation will proceed; otherwise, a message/exception should appear in the program to handle this situation.

Such cases can multiply, including variable overflow, improper type casting or incorrect use of pointers. Fortunately, there are also books available that discuss and teach good programming practices.

Another important aspect of security is the potential for unauthorized access to the device, unauthorized operations or interference with its proper functioning.
Embedded systems are also potentially vulnerable to such attacks, especially when they operate in online mode being connected to the Internet or having interfaces accessible to users, such as USB.

It is up to the programmer to ensure that the protocol they have implemented is resistant to actions that digress from expectations. They must ensure that attacks like DDoS or attempts to impersonate a peripheral device do not allow the execution of code that could lead to errors, data breaches, or falsification.

Electronic thermometer. One of the simplest devices. It operates with a single button, performs measurements, calculations and displays the result being powered by small 1.5V battery. Should there be safety considerations applied to it?
Absolutely! While the thermometer does not directly endanger a person, it can indirectly affect them. Incorrect measurements can lead to misdiagnosis of an illness, a doctor may refrain from prescribing certain medications, or even overdose them.

Another broad aspect of embedded system security is hardware.

Every embedded system developer must deal with the hardware layer that they need to program.

It’s important for the program’s creator to have a good understanding of the hardware they are writing the program for. It seems obvious that writing a program that does not precisely configure the processor’s peripherals will result in unstable operation. Assuming that all parameters will be set correctly by default is a flawed assumption.

Configuring the processor correctly is important, but equally important is verifying whether this configuration is correctly saved. This is where the concept of software testing with verification tests (Unit Tests, Test Driven Development) comes into play.

In critical applications that can impact human health or life, the level of security must be at its highest.

Hardware testing methods are employed for microcontrollers. This includes a complete diagnostic of the CPU, RAM memory, and FLASH memory. Such approach is used in applications where safety is of paramount importance. It involves verifying whether the CPU has the correct configuration, whether any of the RAM memory cells have been physically damaged, and whether any of the FLASH memory cells have been altered compared to what was initially loaded by the manufacturer.

Several methods are used in such tests. For example, one of them involves writing the value 0x55 to a memory cell and then reading it, followed by writing 0xAA and reading it again. Such test reveals that every bit in memory is functioning correctly, with no bits shorted to ground or power.

MOBD is designed and built by Codahead advanced fleet management system with hardware – built with modern technologies like artificial intelligence (AI), Blockchain technology, GPS, BLE and more.
MOBD directly connects to the electronic system of the vehicles.
Having access to the vehicle’s controller could also make changes to various settings.
A drastic example could be disabling the braking system. Therefore, the operating algorithm must be very well thought out to prevent such possibilities.
This device connects to a database server via 4G/5G cellular transmission. In this case, there are several areas where security needed to be heightened:

• Data packets uniquely correlated with a specific device.
• Data packet damage unequivocally detected and resent – two-way communication between the server and MOBD.
• Data packets encrypted to prevent unauthorized, malicious interference from third parties.
• the device can only receive data from the server while the communication protocol must be written in a way that impersonating the server is impossible.
• The GSM modem in the device is resistant to hacker attacks, and the MOBD software detects intrusion attempts.

Well-written software, adhering to safety principles, is crucial, especially for automotive systems like MOBD.

In systems where safety is paramount, there is sometimes a requirement to periodically check whether hardware inputs and outputs have suffered any damage. The software must also perform these tests.

For outputs, the simplest solution is to connect an additional input to the output and, after a signal change, verification whether the change has been implemented. This is the cost-effective solution for digital signals, provided there is an adequate supply of GPIO (General Purpose Input/Output) pins in the CPU.
Of course, GPIO expanders can be used if necessary, as this is a valid approach.

The problem arises when a digital signal from the CPU’s output passes through other circuits and components, such as switches, amplifiers, relays, that introduce delays that are not always constant.

There are several approaches to such problem.
One of them is to continuously monitor the output and check if its state has changed within a predefined time frame. If the change is not detected, the program should report an error.

If the delays cannot be determined, a method can be applied where the output is set to a specific state (e.g., HIGH) for testing, and then the program waits for the change to be implemented.
Subsequently, the opposite state (e.g., LOW) is enforced, and the program again waits for the change to occur. This operation can only be performed if it does not risk damaging any element of the system. Therefore, it depends on the design engineer to determine the appropriate approach.

For analog signals, the situation becomes more complicated because connecting additional measurement input can disrupt the stability and accuracy of the signal. As in the previous case, it is up to the engineer to carefully consider how to control the correctness of the signals output.

Even more challenging scenario is to check whether the measurement system in the device is functioning correctly for analog signals.
The best approach would be to disconnect the measured signal and replace it with a reference signal. This is also the most technically challenging to implement.
So the simpler but intermediate approach would be to create an additional measurement circuit and connect a reference signal with an adjustable value to it. This way, it can be determined whether, within the specified input voltage range, the measurement circuit is providing the values correctly. Continuous monitoring of these parameters in conjunction with the known expected state should allow for effective diagnostics of the measurement system.

Safety in embedded systems entails not only configuring the CPU itself but also all peripheral components.
It’s always worth at least verifying if the configuration has been saved correctly. It is also important to check whether the read data falls within the expected values range.

Aviation and space exploration are areas of technology where safety must be at the highest including the equipment. To achieve desired level, the redundant measurement systems are used, controlling multiple parameters that can affect flight in emergency situations. There are several systems to provide decision-making process onboard and if one among many does not agree with others, the astronauts are being notified. Now it’s all in their hands, not the helping them software.

Another crucial aspect of the safety of an electronic device is ensuring it has a reliable power supply.

When a device is intended to operate using an existing power installation, situations where power might suddenly be lost have to be anticipated. During the design phase, an analysis should be conducted to determine whether a sudden power outage would lead to device failure, pose a threat to operators or bystanders.
Is it worthwhile to implement a backup power source, such as a battery?
The answer is not always straightforward. However, if power outage happens, consider the battery required capacity and how long the device can continue functioning .

Similar considerations need to be made when the device is powered by batteries or utilizes renewable energy sources like solar or wind power. When designing such power systems, it is valuable to analyze meteorological data for the installation area, including hours of sunlight, consecutive windless days, etc. These data points can help determine the size of an energy bank needed to ensure uninterrupted device operation.

The final aspect of safety concerns adapting devices to comply with applicable legal regulations.

During the design process, it is essential to remember that the device must not only function but also meet the requirements for usage and sale. To introduce an electronic device into the market in the EU, it must adhere to the directives of several regulations.

RoHS (Restriction of Hazardous Substances) – a directive of the European Parliament and the Council concerning the restriction of the use of certain hazardous substances in electrical and electronic equipment. In short, it prohibits the use of lead-based solder in soldering and assembly.

EMC (Electromagnetic Compatibility) – this directive applies to devices containing active electronic components. The objective of the EMC directive is to ensure the functioning of the internal market by requiring devices to achieve an appropriate level of electromagnetic compatibility. According to this directive, a device must operate correctly in its intended environment and not interfere with the operation of other devices. Emissions of electric and magnetic fields from the device, as well as its immunity to such fields, are evaluated. There are many tests that need to be conducted to comply with this directive.

LVD (Low Voltage Electrical Equipment) – this directive pertains to electrical equipment powered by voltages between 50-1000 V AC or 75-1500 V DC. It specifies that electrical equipment can only be placed on the market if, following proper installation, maintenance, and use as intended, it does not pose a risk to the safety of individuals, domestic animals, or property.

RED (Radio Equipment Directive) – is a directive regulating the placing on the market of radio equipment. It applies to electrical or electronic devices intentionally emitting or receiving radio waves for radio communication or radio location purposes. It also applies when an electrical or electronic product, which must be supplemented with an additional component, such as an antenna, may intentionally emit or receive radio waves for radio communication or radio location purposes.

For an electronic device to meet the requirements of a specific directive, it must comply with the requirements of the relevant harmonized standards. These standards define the specific requirements for devices. Choosing the applicable standards for a specific device is not straightforward. Various companies specialize in helping select the appropriate standards for a given device, preparing the necessary tests to comply with the standards arising from the directives, and conducting risk analysis.

The above provides a very brief overview of embedded systems’ safety considerations. Should all of these elements be applied? I personally encourage taking into consideration as many of these elements as possible.

Also, if you are interested in what we do at Codahead and how we can help your business grow by implementing innovative software solutions, feel free to contact us at sales@codahead.com.