Embedded systems are hardware-and-software computer systems that perform a dedicated function with a larger system or device. Embedded systems are integrated into industrial machinery, cars, vessels, trains, planes, satellites, medical and scientific equipment.
An embedded system is often hidden inside a device such that the user does not interact directly with the embedded system itself. Embedded systems typically receive input from sensors or a connected data source instead of directly from the user.
Any embedded system is built for a certain application, thus the system should fulfill the requirements of the application. These requirements dictate the characteristics of the embedded system. Three important characteristics are dependability, efficiency, and real-time constraints. These characteristics are crucial since they influence the way the system works.
Efficiency is another issue. The importance of this characteristic comes from the fact that the amount of resources is always limited. Resources can be represented in the form of energy or memory space if it’s an embedded system or as money if it’s a customer. Nowadays, small resource-constrained devices such as wearables or Internet of Things nodes are becoming more and more popular. These devices do not have constant power supply. In general, Energy Efficiency can be estimated based on the amount of work done by the system considering the amount of spent energy. For example, for processors energy efficiency can be estimated based on the number of instructions per joule. It is probably obvious that the number of operations per joule is increasing as technology advances. In general, processors offer the least energy-efficient solutions. Whereas, application-specific integrated circuits are the most efficient ones.
An embedded system typically consists of a microcontroller, also called a computer-on-a-chip. Microcontrollers are equipped with a CPU, memory (RAM and ROM), I/O ports, a communication bus, timers/counters, and DAC/ADC converters.
In an embedded system, hardware and software play equally important roles. If the running software does not exclude the underlying hardware at its full potential Then run-time efficiency will be poor. Inefficiencies cost by poor mapping of the application to platforms should be avoided. Code size is another issue that needs to be addressed when it comes to efficiency. Devices capable of loading additional code dynamically are still rare.
Usually an embedded systems code is stored within the device. Therefore, it should occupy as less space as possible. The physical appearance of the system is not less important. Portable devices should be lightweight so to be more attractive to customers. The last but not the last parameter that influences the overall efficiency is cost. The system should be built using as little components as possible to implement the required functionality.
Real-time systems are computer systems that monitor, respond to, or control an external environment. This environment is connected to the computer system through sensors, actuators, and other input-output interfaces. The computer system must meet various timing and other constraints that are imposed on it by the real-time behavior of the external world with which it is interfaced. Hence comes the name real-time. Another name for many of these systems is reactive systems because their primary purpose is to respond to or react to signals from their environment.
A real-time computer system may be a component of a larger system in which it is embedded; reasonably, such a computer component is called an embedded system. If a real-time system is embedded, we call it a real-time embedded system. Examples of real-time embedded systems are “mission-critical” applications like aircraft controls, anti-lock braking systems, pacemakers, and programmable logic controllers.
A real-time system is one whose correctness depends on timing as well as functionality. A real-time system is a computer system in which the key aspect of the system is to perform
tasks on time, not finishing too early or too late. A classic example is that of the airbag in a car; it is of great importance that the bag inflates neither too soon nor too late in order to be of aid and not be potentially harmful.
A real-time system can be classified based on the acceptability of missing its timing constraints. In hard real-time systems, there are strong requirements that specified tasks be run in specified intervals (or within a specified response time). Missing a timing constraint is absolutely unacceptable. Failure to meet this requirement (perhaps by as little as a fraction of a micro-second) may result in system failure. for instance, if this could result in a loss of human life in the case of pacemakers.
If missing a timing constraint is acceptable but undesirable we call it a soft real-time system. The only consequences of missing a deadline are degraded performance or recoverable failures. Email systems, wireless routers, and your cable box all have real-time constraints that they are designed to meet.
Many systems exist on a spectrum from hard to soft, where it is not unacceptable to miss a deadline, but doing so makes the operation being performed immediately lose all of its value. Systems that lie within this spectrum are often referred to as firm real-time systems.
An event is a stimulus that the system must respond to. These can be initiated in both hardware and software, and they indicate that something occurred and must be dealt with. An event may look most familiar when it comes in the form of an internal or external interrupt. Events can be generated at any time the system detects a change. The time between the moment at which a system detects an event and the moment at which it responds to that event is called latency. Latency is defined as the response time minus the detection time.
A lot of embedded systems are safety-critical and so they must be dependable. For example, errors in nuclear power plants, airplanes, or cars can lead to loss of life and property. The system is considered dependable if all characteristics such as reliability, availability, maintainability, safety, and security are fulfilled. An important issue is that design decisions might not allow achieving dependability afterward, So dependability should be considered during the initial stages of the system design.
The architecture of a Real-time Embedded System
An embedded system has 3 components:
- It has the embedded hardware.
- It has embedded software program.
- It has an actual real-time operating system (RTOS) that supervises the utility software and offer a mechanism to let the processor run a process as in step with scheduling by means of following a plan to manipulate the latencies. RTOS defines the manner the system works. It units the rules throughout the execution of application software. A small scale embedded device won’t have RTOS.
Powerful on-chip features, like data and instruction caches, programmable bus interfaces and higher clock frequencies, speed up performance significantly and simplify system design. These hardware fundamentals allow Real-time Operating Systems (RTOS) to be implemented, which leads to the rapid increase of total system performance and functional complexity.
Embedded hardwares are based around microprocessors and microcontrollers, also include memory, bus, Input/Output, Controller, where as embedded software includes embedded operating systems, different applications and device drivers. Basically these two types of architecture i.e., Havard architecture and Von Neumann architecture are used in embedded systems.
Architecture of the Embedded System includes Sensor, Analog to Digital Converter, Memory, Processor, Digital to Analog Converter, and Actuators etc.
In the last few years, so-called IPCore components became more and more popular. They offer
the possibility of reusing hardware components in the same way as software libraries. In order to create such IP-Core components, the system designer uses Field Programmable Gate Arrays instead of ASICs. The designer still must partition the system design into a hardware specific part and a microcontroller based part.
The first step (milestone 1) architecture design is the specification of the embedded system, regarding functionality, power consumption, costs, etc. After completing this specification, a
step called „partitioning“ follows. The design will be separated into two parts:
• A hardware part, that deals with the functionality implemented in hardware add-on components like ASICs or IP cores.
• A software part, that deals with code running on a microcontroller, running alone or together with a real-time-operating system (RTOS)
The second step is mostly based on the experience and intuition of the system designer. After completing this step, the complete hardware architecture will be designed and implemented (milestones 3 and 4). After the target hardware is available, the software partitioning can be implemented.
The last step of this sequential methodology is the testing of the complete system, which means the evaluation of the behavior of all the hardware and software components. Unfortunately developers can only verify the correctness of their hardware/software partitioning in this late development phase. If there are any uncorrectable errors, the design flow must restart from the beginning, which can result in enormous costs.
The scheduling algorithm is of paramount importance in a real-time system to ensure desired and predictable behavior of the system. A scheduling algorithm can be seen as a rule set that tells
the scheduler how to manage the real-time system, that is, how to queue tasks and give processor-time. The choice of algorithm will in large part depend on whether the system base is uniprocessor, multiprocessor or distributed.
A uniprocessor system can only execute one process at a time and must switch between processes, for which reason context switching will add some time to the overall execution time when preemption is used. A multiprocessor system will range from multi-core, essentially several uniprocessors in one processor, to several separate uniprocessors controlling the same system. A distributed system will range from a geographically dispersed system to several processors on the same board.
In real-time systems processes are referred to as tasks and these have certain temporal qualities and restrictions. The release time or ready time is when the task is made ready for execution. The deadline is when a given task must be done executing and the execution time is how long time it takes to run the given task.
In addition, most tasks are recurring and have a period in which it executes. Such a task is referred to as periodic. The period is the time from when a task may start until when the next instance of the same task may start and the length of the period of a task is static. There can also be aperiodic tasks which are tasks without a set release time. These tasks are activated by some event that can occur at more or less any time or maybe even not at all.
• Release/ready time: The time a task is ready to run and just waits for the scheduler to activate it.
• Deadline: The time when a task must be finished executing.
• Execution/run time: The active computation time tasks need to complete.
• Worst-Case Execution Time (WCET): The longest possible execution time for a task on a particular type of system.
• Response time: The time it takes a task to finish execution. Measured from release time to execution completes, including preemptions.
• Priority/weight: The importance given a task in the context of the schedule at hand.
The scheduling algorithms can be divided into off-line scheduling algorithms and online scheduling algorithms. In offline scheduling, all decisions about scheduling are taken before the
system is started and the scheduler has complete knowledge about all the tasks. During runtime, the tasks are executed in a predetermined order. Offline scheduling is useful if we have a hard real-time system with complete knowledge of all the tasks because then a schedule of the tasks can be made which ensures that all tasks will meet their deadlines if such a schedule exists.
In online scheduling the decisions regarding how to schedule tasks are done during the runtime of the system. The scheduling decisions are based on the tasks priorities which are either assigned dynamically or statically. Static priority-driven algorithms assign fixed priorities to the tasks before the start of the system. Dynamic priority-driven algorithms assign the priorities to tasks during runtime.
There comes a point in the design and implementation of a real-time system when the overhead of managing timing constraints is so great that using any single design pattern or principle no longer becomes feasible. It is at this point that a real-time operating system becomes the best-fit solution. A real-time operating system, or RTOS (pronounced R-toss), utilizes the design patterns of scheduling and queuing, but it adds further functionality including task priority, interrupt handling, inter-task communications, file systems, multi-threading, and more. All this results in the most effective method for meeting and exceeding time-constraint goals.
Popular real-time operating systems include VxWorks, QNX, eCos, MbedOS, and FreeRTOS. The first two in the previous list are proprietary, but the other three can be used for free. MbedOS works with Arm’s Mbed platform, and FreeRTOS has been ported to many different microcontrollers.
However, undertaking DO-178B and ED-12B Level A software certification of an RTOS is extremely expensive, costing millions of Euros and is specific to an underlying processor architecture.
Many aerospace applications are not safety-critical, as their failure may not directly impact the safety of the aircraft, but their failure could impact the success of the mission. So for convenience, we will refer to this broad category as mission-critical systems – this can include non-critical
auxiliary systems, sensor payloads and other applications. These can have a very diverse set of processing requirements in terms of performance and power dissipation depending on
end application and whether the application is deployed in a conduction-cooled or air-cooled environment.
Avionics applications can have strict start-up time requirements; an example of this is electronic flight displays in the event of electrical transients where “recognizably valid pitch and roll data should be available within one second on the affected displays”
This means that after power-failure, the processor must be re-initialised, run a boot loader, and load the real-time operating system (RTOS) and application, then start the RTOS and run the application with meaningful information on the display, all within one second.
A requirement which programmes may overlook when embarking on a DO-178 certification project, is the certification of the firmware initialisation code which runs from the processor’s reset address after a power reset and performs hardware initialisation before the boot loader loads and runs the RTOS.
References and Resources also include: