International Defense Security & Technology Your trusted Source for News, Research and Analysis
Related Articles
science fact. Smartphone connectivity, high-powered entertainment systems, navigation,
interactive systems feedback, driver responsive performance – the list of advancements
goes on. The software used in cars is getting more complicated – and more connected.
In automotive systems more and more equipments are being changed from the mechanical systems to electronic systems. Embedded system is the heart of a vehicle’s electronic system because of its versatility and flexibility. The revolution of electronics has manipulated in automotive design including the fuel combustion, power train crash protection, etc.
Advanced usage of embedded system in vehicle can help in controlling the pollution, increasing the facility to provide systems monitoring features that consumers demand. Today a typical vehicle contains around 25 to 35 microcontrollers, and some luxury vehicles contain approximately 60 to 70 microcontrollers per vehicle.
The embedded Navigation System consists of embedded circuitry built with a GPS receiver, a gyroscope, a DVD-ROM, main controller and a display system. The GPS receiver receives the current longitude and latitude values that are compared with the stored map. The Gyroscope and other sensors provide the road direction and speed. From all the information gathered at the main controller, the display system displays a navigation or route map of the destination in the display screen.
Adaptive cruise control allows cars to keep safe distances from other vehicles on the busy highway roads. The driver of the car can set the speed of his vehicle and the distance between his car and other vehicles. When the traffic slows down, ACC changes vehicle speed using moderate braking. Each car has a laser transceiver or a microwave radar unit which is fixed in front of the car to find out the speed and distance of the any other vehicle in the pathway.
The automatic parking system is an independent car manipulation system that moves a car from traffic lane into a parking spot to perform the parallel parking, perpendicular parking and angle parking. This system mainly uses different methods to detect objects around the car. Sensors installed on the front of the vehicle and rear bumpers acts as both a transmitter and a receiver. These sensors send a signal that will be replicated back when it meets an obstacle near the vehicle, and then the carputer will receives the time signal and bumper will use the radar to decide the position of the obstacle. The car will sense the parking space and distance from the side of the road then drive the car into the parking place.
System requirements
- Safety
The demand for safety will impose some important functional and non-functional constraints on the embedded systems of the drive-train and chassis. These demands aren’t usually driven by legislation but by competition between manufacturers.
-
- Hard real-time constraints: it is imperative that all safety related systems comply to real-time constraints. Systems like ABS should be able to react within mere milliseconds to ensure a timely intervention. This not only puts a constraint on the processors-speed, but also on the speed of the communication system used throughout the car, because these systems often rely on input signals from other systems and need to send outputs to different systems as well (e.g. ESC-system must communicate with engine management).
- Fault-detection: every sub-system of a safety-critical function should be capable of auto-diagnosing of its function and should be able to switch to a safe shutdown condition in case of failure. Obviously also the communication system should be able to perform data-transfer checks. Legislation dictates that if a fault is detected, this should also be shown to the driver (MIL Malfunction Indicator Lamp) and be stored in the fault-memory of the controller.
- Redundancy: critical sensors, like the throttle in drive-by-wire systems, should have redundancy to minimize malfunction probability.
- Reset-time? Start-up-time?
- Cost
As in all industries manufacturing cost is also very important in automotive.
- Emissions / fuel-economy
The main driver behind emissions-constraints has always been legislation, even though more recently fuel-economy has become an increasingly more important sales-argument. A very important aspect of this legislation is the On-board diagnostics (OBD), which monitors the engine-system continuously to ensure compliance with emission-laws in everyday use. Some of the most important demands for the drive-train-system are:
-
- Monitoring of emission-related electrical components (e.g. short-circuits) and storage of fault (OBD 1).
- Monitoring of system functionality (e.g. plausibility check of sensor-signals) (OBD 2)
- Components used to monitor emission-related components of which affect diagnosis must be monitored. (OBD 2)
- Monitoring frequency is usually prescribed by law.
- Malfunctioning must be displayed to the driver by MILs (Malfunction Indication Light).
- Time to market
Drive for shorter time to market pushes the system development towards more interchangeable components. This is currently very difficult because there are no clear communication standards. Bus-communication systems have made it a lot easier to introduce new functionalities into existing systems.
- Passenger comfort
Passenger comfort is also very important in automotive due to competitive reasons. These requirements mostly apply to systems in the interior and telematics area. This gives also some constraints on the embedded systems:
-
- Soft real-time constraints: many non-critical systems (e.g. electric windows, electric mirrors…) have prescribed timing constraints, but violating these constraints doesn’t have serious effect. A lot of these systems for example have to react within 100ms, with is the limit of delays a human can perceive.
Design process
Embedded System is an electronic system or device which employs both hardware and software. A processor or controller takes input from the physical world peripherals like sensors, actuators etc., processes the same through appropriate software and provides the desired output. The various components have to communicate with each other to provide the anticipated output.
For the design of embedded automotive systems, the entire vehicle system is usually split up into four different functional areas, which could be separated during the design phase: Chassis, Drive-train, Body, and Telematics
An embedded system is an electronic or computer system which is designed to control, access the data in electronics based systems. This system includes a single chip microcontroller such as cortex, ARM and also microprocessors, FPGAs, DSPs, and ASICs.
The different type of microcontrollers used in embedded systems are:
- 8-bit or 16-bit Microcontroller
- Serial and Parallel Input-Output
- Analog to Digital and Digital to Analog Conversions
- Flash Memory and PROM
- Signal generators and Timers
Embedded systems in automotive usually follow a model-driven design workflow. This will be followed by basics of Model based Development, guidelines in developing compatible model based development models, followed by testing theories & techniques.
Functional requirements should generally be taken into account during the functional design stage. This also includes fail-safe modes.
The timing constraints should be taken into account during the implementation stage. It is very important to make sure the hardware is capable of reaching the timing constraints, but is not to performant either. Also the demands for the communication-speed should be taken into account during this phase. If the communication-speed is very critical it might even be necessary to include a detailed model of the communication network in the original vehicle model. All the monitoring functions for hardware malfunctioning can only be designed during this stage as well. Crucial functions that have to meet real-time constraints will usually require their own hardware to assure real-time operation, so this is a constraint that should be taken into account from the start of the design. This might be very difficult in practice.
A very important design-phase is the configuration of the communication between the different vehicle-systems. Due to the ever increasing amount of signals and lack of standardization this is currently very time-consuming. The AUTOSAR standard is meant to strongly facilitate this stage.
Hardware
Originally, cars were equipped with single signal cables. As electronic systems increased in number and complexity, this approach was no longer acceptable due to cost, weight and complexity. This is why manufactures have switched to bus-systems (e.g. CAN-bus) for in-car communication between the different systems. There are usually several buses in one vehicle, each system adapted to the speed demands of particular system-groups. More information on these bus-systems can be found in the chapter on field-buses.
Most functionalities are currently programmed in a microcontroller with program memory (EPROM or flash ). Due to the wide array of functionalities, there is a wide range of sensors in modern cars. Sensors on safety-critical components (like ESP-sensor) are required to have internal self-monitoring functions as well.
The future
Looking further in the future, these trends seem to continue. Cybercars or driverless cars for example need to know the state of the whole vehicle to control the vehicle in an optimal way. This can only happen when there is central software. In the far future, there might be a trend toward communication between cars and between cars and road infrastructure.
An example is a fleet of cybercars. A fleet of such vehicles forms a managed transportation system, for passengers or goods, on a network of roads with on-demand and door-to-door capability. This kind of system belongs to the class of ‘distributed hardware – central software’. The fleet problems concern essentially the following elements: – vehicle allocation to a particular demand, – vehicle relocation after a trip, – deadlock avoidance, – demand management and fare collection, – distributed versus central management, – communication architecture.
Instead of a fleet of cars which are controlled by a central management system, one can imagine that there will also be a quest for autonomous cars who only communicate with their surroundings and possible a central system to gather traffic information. This car can then decide autonomous what action he should undertake.
Software Architecture
To streamline the coordination between OEMs and tier 1 suppliers, to improve ECU software quality and reduce development time and costs, tier 1 automotive suppliers, semiconductor manufacturers, software suppliers, tool suppliers, and others came forward in 2003 and created a consortium called AUTomotive Open System ARchitecture (AUTOSAR).
AUTOSAR is an open software architecture standardized by the automotive industry. Autosar architecture specifies a standard interface between application software and basic vehicle functions. AUTOSAR is intended to provide inherent benefits to the members to manage increasingly complex E/E in-vehicle environments
Autosar architecture is described by Layered Software Architecture. Layered architecture describes a top-down approach to the hierarchical structure of AUTOSAR software and maps the Basic Software Modules to software layers and shows their relationship.
AUTOSAR is intended to provide inherent benefits to the members to manage increasingly complex E/E in-vehicle environments like easy integration and exchange of functions in complex ECU network and control over the entire product lifecycle.
Autosar facilitates software development independent of hardware, with the standard software is more transferable. This means software can be easily shared between different vehicle systems largely independent of the system’s underlying hardware, which AUTOSAR improved by standardizing component interaction. In the past, and still today, most component software is developed according to the hardware it will be programmed on. AUTOSAR reduces this constraint by implementing a standardized interface between application software and its hardware to allow for hardware-independent component software. The standardized interface allows application software to communicate by utilizing a Virtual Function Bus (VFB).
The AUTOSAR Architecture distinguishes on the topmost abstraction level between three software layers:
- Application Layer,
- Runtime Environment and
- Basic Software (which run on a Microcontroller)
The application layer is the topmost layer of the AUTOSAR software architecture and supports custom functionalities implementation. This layer consists of the specific software components and many applications, which are a group of interconnected AUTOSAR Software Components and perform specific tasks as per instructions.
The RTE layer provides communication services to the application software for example AUTOSAR Software Components and/or AUTOSAR Sensor/Actuator components. RTE Layer provides ECU independent interfaces to the application software components. The application layer consists of many SWC which does not follow layered architecture style but component style. The Software Components communicate with other components (inter and/or intra ECU) via the RTE.
- The AUTOSAR Basic Software (BSW) is further divided into three layers:
- Services Layer,
- ECU Abstraction Layer,
- Microcontroller Abstraction and Complex Device Drivers (CDD).
- Microcontroller Abstraction and Complex Device Drivers (CDD): CDD or MCAL is also known as a hardware abstraction layer and implements interface for the specific microcontroller. MCAL has layers of software, which are integrated with the microcontroller through registers, and offers drivers like system drivers, diagnostics drivers, memory drivers, communication drivers (CAN, LIN, Ethernet, etc.), I/O drivers and more.
- ECU Abstraction Layer: The prime task of the ECU abstraction layer is to deliver higher software layers ECU specific services. This layer and its drivers are independent of the microcontroller and dependent on the ECU hardware and provide access to all the peripherals and devices of ECU, which supports functionalities like communication, memory, I/O, etc.
- Service Layer: The service layer is the topmost layer of AUTOSAR Basic Software Architecture. The service layer constitutes an operating system, which runs from the application layer to the microcontroller at the bottom. The OS has an interface between the microcontroller and the application layer and can schedule application tasks. The service layer in BSW is responsible for services like network services, memory services, diagnostics service, communication service, ECU state management, and more.
