Introduction to Embedded Computing Systems part III Davide - - PowerPoint PPT Presentation
Introduction to Embedded Computing Systems part III Davide Bertozzi davide.bertozzi@unife.it Embedded Software Architecture Applications Application Layer File system Memory Mgt Task Mgt System Service Layer Embedded Operating System
2
Board Support Package Device Drivers
Task Mgt File system Memory Mgt
Application Layer System Service Layer Embedded OS Layer Hardware Abstraction Layer
The hardware abstraction layer (HAL), as a part of the OS, is a
In general, the HAL includes the bootloader, board support
Similar to the BIOS in PCs, the bootloader is a program that
starts whenever a device is powered on to activate the right
unauthorized software installation.
The BSP achieves the abstraction of the hardware operation,
empowering the OS to be independent from the hardware and enabling the OS to run on different hardware architectures.
Device drivers enable the OS to have a unified software interface
to operate different hardware components and peripherals.
3
An embedded OS is the system software, mainly used to:
Ensure the embedded system operates in an efficient and reliable manner by managing hardware and software resources.
Provide an abstraction layer to simplify the process of developing higher layers of software.
Abstract many hardware functions and provide them to applications in the form of services.
Scheduling, files synchronization, and networking are the most common OS services
Act as a disk partitioning tool (if any)
These goals are achieved via a kernel that provides at least:
Process management
Provides the illusion of simultaneous multitasking on a processor core
Provides task implementation, scheduling and synchronization, and inter-task communication
Memory management
Dynamic memory allocation and deallocation, with deterministic allocation time
Minimize memory fragmentation
Virtual memory management (if any)
Memory protection
System I/O management
File management mechanisms on various memory devices (Flash, RAM or disk)
Device drivers for uniform I/O access
Communication management between I/O and processes
4
The software developers are concerned on the role of the embedded OS
differentiators between embedded operating systems in this regard are:
Memory Management Scheme, i.e., virtual memory swapping scheme and page faults.
Scheduling Policy of processes.
Performance, i.e.,
Response time, to make the context switch to a ready task and waiting time of task in ready queue
Turnaround time, how long a process takes to complete running
Scheduling overhead, the time and data needed to determine which tasks will run next
Fairness, what are the determining factors as to which processes get to run
More fundamental questions include:
Can this OS support my hardware? Are there any performance limitations? How about the memory footprint?
Has the OS been STABLY ported onto the hardware platform?
Does it support real-time execution?
Is it modular and easily customizable?
5
Common embedded OSs include:
Embedded Linux,
VxWorks,
AMX
RTXC
OS-9
OSE
RT-Linux,
Android,
OSEKturbo
ThreadX
LynxOS
VxWorks, an embedded real-time operating system (RTOS) from Wind River, supports PowerPC, 68K, CPU32, SPARC, I960, x86, ARM, and MIPS. With
military, aerospace, aviation, and other areas that require highly sophisticated, real- time technologies. In particular, VxWorks is used in the Mars probes by NASA.
It is currently the most widely used OS in industry 6
eCos
Integrity
Nucleus
PikeOS
Symbian OS
Palm OS
uCLinux
TinyOS
Blackberry OS
Windows CE,
Windows Embedded
....
The application, located at the top level of the software hierarchy, implements the system functionality and business logic.
From a system perspective, each application is a separate OS process. Typically, applications run in the less-privileged processor mode and use the API provided by the OS to interact with the OS
Embedded systems do not have enough resources to run development and debugging tools. Therefore, embedded system software usually uses cross- compile development, which generates execution code on another hardware platform.
The cross-compile development environment is built on the host, whereas the embedded system is called the target machine. The cross-compile, assemble, and link tools on the host create the executable binary code, which is not executable on the host: only on the target machine. The executable file is downloaded to the target machine. The development environment on the host doesn’t completely reflect the environment on the target machine, so debugging and fault diagnosis of the target machine can be time consuming.
7
Embedded processors are functional to the final product, they
This implies a requirement: lower price!
Without today’s embedded processors, features such as «anti-
Next trend: embedded processors to make «generic
A world of smart devices, in which virtually any product contains
its own processor, connected through the internet.
INTERNET-OF-THINGS (IoT): an object X is replaced with the
intelligent networked X. A variety of benefits and applications come from this.
E.g., previously «mute» surfaces and objects start delivering us data.
8
Lots of data to process (the «data deluge») and/or complex processing requirements for them (e.g., «big data analytics» based on «machine learning») are leading to offload computation to the Cloud.
Non-Cloud devices capable of some form of data processing, close to sensors, actuators or IoT service users, are called «Edge Computing Devices».
But the Cloud is expensive, comes with latency penalties, and is not good for data privacy. Therefore intermediate forms of high-performance computing are being introduced. However, it is impossible to completely get rid of the Cloud!
9
Smart sensors Edge
Source: ESG Research 2016
10
Current IoT service providers are (right now!) statically splitting the workload of their application between smart sensors, tablets/smartphones/gateways, Fog computing nodes, and the Cloud
Advances in IoT technologies are pushing computation and storage requirements to the edge
Source: ESG Research 2016
11
The concept of Cloud-Things continuum is emerging as a (quasi-)continuous segment that connects the Cloud with IoT devices, along which service instances processing IoT data can be instantiated and dynamically relocated (dynamic topology deployment of IoT applications) Can we improve the interaction between these computing segments thus providing new IoT services? For instance, why not migrating workload dynamically from one segment to another?
Tighter interplay across devices?
Fog Computing is a new market for high- performance computing machines The new environment for these machines means new design challenges. The first one: resources outside the Cloud are scarse!!
Services must be isolated to ensure security Multiple IoT services will share the same Fog Node Most IoT applications are context-sensitive Low-overhead and efficient sharing mechanisms! Integrated HW/SW support for security Ways to support and/or exploit fluctuating workloads over time
Other challenges to be tackled with cost-effective solutions:
13
Smart Home Smart cities & Transport Networks Smart Health Networks Smart eGovernments & eAdministrations Smart Energy Networks Smart Industry