Embedded Software Architecture

Scope of this document

This document mainly focuses on the importance of Architectural design used in Embedded Project. It shows the significance of Architectural design. It lights on the side effect of bad or no design in the project. This document mainly divided into 2 Parts –

Part I mainly targeted for beginner. This portion is designed to groom the mindset of new entry into embedded field and seeking guidance to understand what & how basic design of Embedded Project done in companies. It also answers about why such designs are needed.

Part II mainly targeted for Intermediate. Since at this level user almost acquaint with most of the basics. But seek guidance in channelizing those skill set for better embedded project design. Pending

Software Designing – Concept & Importance

As in our real world without a design blueprint or a plan we cannot construct infrastructure, R&D projects remain directionless, Governmental organization cannot run economical bodies.

Similarly, Software domain is the one which has multi-applications. It deals with People in their day-to-day life. In today’s world any kind of intelligent machines are just a piece of junk without software.  Hence, software needs to be designed elegantly to make best use of the piece of iron.

Any existing software which challenges designer for following –

1. Restriction for feature expansion
2. Maintenance Overhead

Not considered as good quality software.

How it affect industry?? It affect mainly because of followings –

1. Time to Market will be large
2. Competitor Overrun
3. Product stability not guaranteed
4. Cost of the product

That is the main reason why Software designing concept introduced. It helps designers and hence the stake holder to give futuristic optimizations. It means one can easily be able to identify what are the basic capabilities of the software & the hardware associated with. And hence the timely Scope of product improvement/enhancement can be decided. It provides a pictorial view of whole system. And seeing a pictorial representation is more creative then imaginary analysis.

Why to plan an end-to-end Firmware design

Every Product when designed, manufacturer main intent is to maintain it for long run. Hence the basic philosophy behind end-to-end design is –

1. Scalability
2. Maintenance
3. Easy-to-Understand

Scalability – Meaning to facilitate extension/contraction. When it comes to Software designing it holds true. One of the attribute of Software design is scalability. Market environment changes very rapidly. Based on market requirement the product needs to add new features time-to-time. And also old/obsolete features need to be eradicated or deactivated. This further entitled portability, modularity, Reusability.

Maintenance – Bug tracing & Bug Fixing

Users are the actual end-tester of the product. So, bug could occur from any corner of the design. Hence, Software design must facilitate bug traceability and then the bug fixing.

Easy-to-Understand – Based on the workload team-size may vary. Based on the commonality among products, different teams in an organization do use same software design. All new members must find the design easy to understand, easy to work on.

Basic Foundation Architectural layer for Embedded Software –

Fig. 1) Basic Architecture Layer

        

Above arrangement is the core hierarchy arrangement of Firmware design. Hardware Layer remains as the bottom act as a source of needful parameter. System Software act as an intermediate layer helps to translate the parameter to a format which allows application to use it. Application Layer is the one which interact with user, allows a command interface to user for communicating with the machine/device. It facilitates basic feature implementation of the product. And also controls underlying layer by configuring and providing appropriate user input.

This is commonly known as Layered Architecture Design. Such designs form the core structure of software in many areas. Automotive Sector, Electrical & Electronic Sector, Lighting Sector etc.

Importance of Layered Architecture

From a long-run perspective designer have to anticipate following challenges –

1. Enhancement in system requirement which may require a change in Hardware.
2. Enhancement in existing feature which was not utilized yet.
3. Improvement of available features
4. Bug fixing

                                            Fig. 2) Generic Vs Architectural Design

Generic Design is not the exact match for above challenges, because it has huge amount of dependency among each elements, whereas in case of Architectural Design most of the challenges handled smoothly. Below is the comparison table for both.

	Generic Design	Architectural Design
H/W Changes	Will severely affect the Overall design. Because most of the components have direct link with H/W.	Max-to-Max the affect is limited to System Software where H/W drivers & its interface reside
Feature Enhancement	This need inclusion of new hardware or change in existing H/W. Developer needs to write new driver and include the same in the existing design. But due to the clumsy structure   overall work is not that smooth	Here the structure is almost pre-defined. One simply needs to define driver and its interface to application.
Feature Improvement	This also need individual to exercise the dependency & side-effect on overall system	Here the degree of dependency & side-effect does exist. But it mostly one-to-one. And that can be easily figured out due to its plane structure.
Bug Fixing	It’s a time consuming process. Since, the complex structure restricts to give immediate clue about erroneous source.	Here it provides the bug tractability. It’s a procedural approach
Time-to-Market	Prediction is out of bound. Dependency chain affects entire development cycle pace.	Here the capabilities, scope, affected areas are well identified before development cycle. Hence it has a deterministic and predictable time bound.
Maintenance	It’s very hard and costly	It’s fairly simple.

“Architecture is what makes the sets of parts work together as coherent and successful whole”

Best Fit Case

Automotive industry categorized into various mainstream players –

1. OEM
2. Tier-1 Supplier
3. Tier-2 Supplier
4. Autosar Partners

OEM use to outsource many development activities to third-party vendors. In order to maintain proper synchronization among different work, all has to agree upon a common standard. Now days mostly adopted one is Autosar. Autosar gained popularity in last 10 Years mainly because of its stable structure.  

Definition of Basic Layers Application

Application Layer mainly provides the basic feature definition for the product.

To be more precise, all underlying layers provide mainly general services. Using combination of these services in addition to some more logic and algorithm one can creates a feature.  And this activity is dedicated to Application Layer.

In addition to above, Application Layer also set User Interface. Because this is the area where user drops their input in the form of action/data/command and expects appropriate response. Hence, Application also needs to have a database for quick look up for User expectation. So, this could be command_response database.

Now application acquires the user input via user interface but how it conveyed to the target? Target could be anything – a microcontroller used inside/outside the system, a computer system connected in the network, or could be an IoT cloud. Data for these devices need to be handled & channelize differently. So, here some communication interface needs to be defined which responsible for selecting appropriate communication services from underlying layer.

Application could be implemented for multi-tasking purpose. Hence, the platform must be a scheduler based which further classify application as a scheduling based application. Hence, there may be variety of Scheduler tasks running for serving the application. Hence, an Application interface must define to choose appropriate function for particular tasks. Apart from all above there are many elements which are very specific to product, users, geography, region etc.

                                                Fig. 3) Basic Application Layer View

System Software – Middleware, Generic & Architecture-Specific Device Driver

System Software provides the services from the hardware.

Services can be classified as communication services, Flash storage, Alarm & Timer, data services, indicator services and many more.

The main charisma of this layer is the independency it brought in for entire systems. Extraction of actual real world data from Hardware Layer confines well within System Software layer & its sub-layers. The functionality of each Sub-Layers never miss-spill with adjacent layers. Perfect harmony among the functionality of each Sub-layer maintained in order to smoothen the overall working.

How System Software achieve independency & harmony??

This mainly accomplished by defining 3/4 sub-layers. These are –

1. Device Drivers (Generic & Architecture-Specific)
2. Higher Layer Interface -- 2) & 3) Combiningly form Middleware
3. Service Layer
4. Scheduler (monolithic or micro kernel)

Device Drivers –

These are mainly the hardware drivers. They contain the routine to directly operate on the MCU registers. Hence, they directly access the hardware peripherals. These routines ultimately manage 4 basic function related to hardware – Initialization, Read, Write, Start & Stop. These also called as Microcontroller Abstraction Layer (MCAL).

Higher Layer Interface –

Device drivers are the sensitive areas where isolation needs to be maintained between immediate upper layers. Any interdependency ruins the overall structure of architecture. This isolation provided via callback mapping & parameter pointers to upper layer.

Service Layer –

Service Layer classifies the available services obtained from MCAL. These are – Communication, Security, and Memory etc. So, application only has to focus on these available services rest will be taken care by its own from the underlying layer.

Scheduler –

Scheduler or Kernel is the main administrative body in the entire design. It decides the scheduling of various functionalities. Usually Schedulers are of types – Monolithic & Micro-Kernel

Monolithic is the one which has everything as single set of kernel.

Micro-Kernel has an individual entity of Kernel with no sharing of Kernel space for other occupancy.

Hence, Scheduler can come as pack of Device drivers or has middleware intact in it. The only measure need to be taken for Scheduler is the standards used. Standards can greatly impact the design of system. One of the key standards implemented in off-the-shelf embedded OSes today is portable operating system interface (POSIX). It holds all the basic feature definition for Process Management, IO Management & Memory Management and many more. System Related Services like task creation & management, Resource management etc. are provided by this entity. The board support package (BSP) is an optional component provided by the OS provider, the main purpose of which is simply to provide an abstraction layer between the operating system and generic device drivers.

                                                      Fig. 4) System Software Layer View

Hardware – MCU, On-Chip & Off-Chip devices

Hardware Layer provides the actual real-world data.

This mainly consist of intelligent CPU for dealing with user situation like – Sending/Receiving data to/from other devices, Fetching data from Sensors, Storing data to NV Area, running IO devices like counters for monitoring a scenario. These are very limited list of user situations.

This layer should possess adequate resources to manage variations for future market requirement. Usually system designer & Architects are extremely cautious while designing this layer. Any miss will have direct impact on Middleware & Application.

                                                           

                                                     Fig. 5) Basic Hardware Layer View

Mediaeval (Legacy) Elements

Many products occupy market for much longer time. During the course it gains stability and popularity among consumer. Company gain confidence in such kind of product and it’s a thought process built thereafter. Legacy Elements are somewhat which has been used from longer time and assume to bring core benefits to the product operation. Such elements sometime need to be retained even during any architectural changes.

Software developer advised to create a Wrapper for such element. Many languages do have dedicated mechanism for this. Wrapper creates a kind of abstraction. It hides the information from being exposed and yet achieves the same performance as available previously.

Wrapper placement in architectural design decided based on the element which it target. E.g. if Legacy element is for drivers or services then wrapper is confined within System Software Layer. Or if Legacy element is for some application specific functionality then Wrapper built at Application Layer.

Practical Use case

Consider a design case for GUI based data acquisition system. Below are the overall system requirements –   

1. Periodic data of 3-channels – Temperature, Pressure & Humidity need to be reported per 10mins
2. Data accumulated must be logged in some database
3. After every 24Hr per day report must be reported to the cloud
4. User must have GUI control to see the dynamics in graphical format along with control to ON/OFF the scanning of channel

Step 1 – Identify H/W & Scheduler

1. MCU with 128KB RAM & 512KB ROM and >3 channel ADC. LPC2148
2. LPC2148 has 12-bit ADC. Hence sensors for temperature, Pressure & Humidity must be appropriately chosen.
3. External EEPROM for logging data. Let’s choose I2C based EEPROM.
4. Graphical Driver for display. Need to identify on-chip or off-chip device. Also need to check if it has graphical library or not. Let’s opt for off-chip device from Microchip PIC24FDA series which has well-defined Graphic control library.
5.  A TCP/IP port for sending the data to cloud. LPC2148 has in-built TCP/IP feature
6. Scheduler for managing various tasks. Let’s opt for FreeRTOS. This also has port for LPC2148.

Step 2 – Identify S/W components

1. I2C driver for memory access
2. ADC driver for capturing Temperature, Pressure & Humidity
3. Graphical driver for Graphical display
4. An interface to communicate with Graphic controller. Let’s assume UART
5. A TCP/IP stack for communication to cloud.
6. Few Scheduler task for making the system Run.

Step 3 – Develop Conceptual Design – UMLdiagrams (Beyond the Scope of this document)

Step 4 – Overall System Architectural View

                                                          Fig. 6) Overall Architectural View

Significance of Structure Pointers & Callbacks

These are the key programming constructs used for holding overall design firmly.

Structure Pointers – They are considered as the packet chunk moving to down layer from up layers. These are constructed at the source point mostly at application layer and passed layer by layer to H/W. Any future h/w changes, feature enhancement/deletion will majorly affect the change at source. Rest all underlying layers either have no changes or experience minimal change.

Callbacks – Any driver or MCU h/w stuff recommends isolation before direct use. Callback plays a crucial role in defining these isolations mainly in the interface layer. Any future h/w changes simply require appropriate callback mapping.