Monthly Archives: August 2020

Why Cybersecurity Has Become Indispensable for Automotive Industry

The moment a system is connected to a network, it becomes vulnerable to cyber-attack. The attack may or may not be a successful one, depending on how secure the network is.

We witness the news of website/email hacking or the hijacking of social media accounts umpteen times. Movies go a few steps further to showcase how a full-blown cyber-attack on a government installation would look like. That might look like a bit of exaggeration but theoretically, such attacks are possible.

Now, that automobiles have also joined the digital bandwagon, the security threat has become real for them too. For example, a connected car is akin to a computer on a network with exposed interfaces such as steering, braking and other vital information about the occupants. A hacker can interfere with the vehicle systems or steal sensitive data if he gets access to the vehicle.

This might seem far-fetched but there have been such incidences in the past that corroborate such claims. Moreover, some researchers have performed such cyber-attacks on infotainment and other systems to bring out their vulnerability to cyber-attacks.

However, automotive OEMs and other entities in the automotive value-chain do realize these threats. The introduction of a cybersecurity standard ISO-SAE DIS 21434 is also helping in making cybersecurity a part of the software and hardware development lifecycle.

We will learn about all these aspects in the subsequent sections of the blog. Read on..

Why is Automotive Cybersecurity Such a Big Deal?

Automobiles have transitioned from being wheels driven by an engine to a sort of data center on wheels. A modern-day car with some advanced features can have 150 ECUs with more than 100 million lines of source code. The cyber risk to a modern vehicle increases with every line of code burnt on the automotive ECUs. Hence, each line of code must conform to the measures stipulated in the cybersecurity standards.

Moreover, the threat is not just limited to the vehicle itself but also transcends to the back-end and 3^rd party services. A good example of an attack on such services is controlling a home EV charging installation by accessing the home Wi-Fi.

When we bring connected and autonomous vehicles into the picture, the threat can take a more hazardous form.

We have summarized some findings from last year’s cyber-attack incidences:

1. An SUV was hacked by a few white hat hackers to control the climate control feature, infotainment system and even steering and braking system. Fortunately, this hack was part of a research done by some cyber-security experts.
2. The percentage of black hat hacking incidences (hacking done with malicious intentions) had risen to 72% in the first few months of 2019.
3. Keyless remote entry, a popular feature in vehicles, has been the preferred vector for cyber-attacks.
4. A parking garage meant for employees of a Canadian organization was attacked by a ransomware that allowed free parking and even without verification of the access cards. This attack was a classic case of attack on back-end systems meant to facilitate automobile users.
5. In an incident of attack on an alarm system server, the hackers were able to track the vehicles, unlock their doors and even cut off their engines in some cases.

Every new feature or functionality added to a vehicle system adds to the risk of cyber-attack. In order to mitigate them, we must first understand the threats and where they emanate from. Let’s learn a bit about that too!

Automotive Innovations and Cybersecurity: Understanding the Threat

Automotive industry has been innovating at an unprecedented pace and most of it is driven by software. And we have already discussed how each line of code in the software increases the vulnerability. According to Mckinsey reports, the software and E/E component market is expected to grow from USD 238 billion in 2020 to USD 469 billion over the next 10 years. Let’s understand the cyber threat that emanates from these innovations:

1. Connected Cars: Automobiles are evolving rapidly into connected devices equipped with Bluetooth and Wi-Fi based communication. Technologies like vehicle to infrastructure, vehicle to vehicle, vehicle to cloud, and vehicle to everything make the car vulnerable to cyber-attacks. Once, the hackers get access to the vehicle to cloud network, they can potentially hack the entire fleet of vehicles connected to that cloud network.
2. Highly Autonomous Vehicles: Autonomous vehicles once seemed like fables straight from a fiction novel or a sci-fi movie. Fast forward to 2020, OEMs have driven the autonomous vehicles millions of miles on the roads. These vehicles rely not only on the sensors fitted in the car, but also a stream of data from the infrastructure around them including GPS and traffic data. Any breach in the system can lead to fatal accidents.
3. Electric Vehicles: The cybersecurity aspect of an EV is no different than an IC engine vehicle. However, an added vulnerability in the form of Electric vehicle charging station is added when cybersecurity is discussed in the context of electric vehicles. A cyber-attack on the charging infrastructure can lead to serious consequences like fire and power issues.

Source: Joelynn Schroeder, NREL

Vehicle Cybersecurity Across Value-Chain

Different components of a vehicle are developed by multiple entities viz, OEM, Tier-1 supplier, After-market vendors, Technology solution providers and others. These components need to be developed keeping in mind the cybersecurity aspect. Hence, the approach has to be uniform across the automotive value-chain.

Following are some of the stakeholders and their role in ensuring automotive cyber-security:

• Original Equipment Manufacturer: OEMs are responsible for crafting a vehicle with its trademark characteristics. In this process, the OEM procures different components from Tier-1 and After-market suppliers. Hence, it is the role of the OEM to define clear guidelines on the cybersecurity aspects to follow. While sourcing technology from other vendors, they have to make sure that they follow these guidelines across the development process. Compliance with cyber-security standard ISO/SAE DIS 21434 can act as a good reference point for this activity. The OEM must ask for work-products (evidences) of their compliance with the standard.
• Tier-1 Supplier: Tier-1 suppliers must be aware of the cyber risks involved in the component that they are providing to the OEMs. For instance, an Android-based infotainment system provided by a supplier must conform to development keeping cyber-risks under consideration, both at the software and hardware levels.
• Technology Service Provider: Tier-1 suppliers often outsource technology solutions development to product engineering service providers. These vendors provide design and development support including reference designs, prototype development, automotive protocol stacks configuration and integration, testing services and more. Similar to the Tier-1 suppliers, the technology partners should also be in sync with cyber-security requirements that have been defined at the top of the pyramid, i.e. by the OEMs.

Understanding the Types of Cyber-attacks on Vehicles

Over the years, cyber-attacks have evolved and so have their prevention methods. However, in order to keep vehicles safe from these threats, it’s imperative that cybersecurity measures are always in place. And to ensure that, we must first understand the kind of threats that can affect a vehicle.

Denial of Service (DOS): It is an attack that overwhelms an automotive system to make it unresponsive to requests. For example, a DOS attack on the ABS ECU can disable the braking system of the vehicle. A DOS attack does not give the hacker access to the system, but it can surely be used for malicious intentions such as injuring a vehicle occupant.

Man-in-the-middle (MitM) attack: When a hacker inserts himself between the client and the server, it is called a MitM attack. In such an attack, the attacker can spoof the client and steal data from the server.

Command injection data corruption: By injecting a specialized command, the attackers can gain a write access to an ECU and corrupt the data stored in the ECU. Depending on how critical the ECU is, such attacks can wreak havoc on a vehicle system.

There are many such types of attacks possible. Once the attackers are aware of the vulnerability, they can choose the mode of attack.

Best Practices to Achieve Vehicle Cybersecurity

As mentioned earlier, cybersecurity measures must be followed across the development lifecycle (security by design) of an automotive component. On top of that, there are certain best practices that aid in achieving cybersecurity in the entire automotive ecosystem. Let’s discuss a few of them.

• Interfaces to the outside world should be secure. These interfaces include over-the-air update (OTA), OBD, Bluetooth and Ethernet.
• ECUs that are safety-related should be isolated and protected using secure gateways.
• Apart from software related measures, Hardware Security Module (HSM) must be implemented for Microcontroller platforms. HSM plays a key role in delivery of security services like Trusted Execution Environment (TEE) for the applications.
• Automotive cybersecurity guidelines as mandated by ISO 21434 must be followed by all stakeholders across the automotive supply-chain.
• Protocol stacks such as UDS, DoIP, SOME/IP, FlexRay must be developed as per the cybersecurity guidelines and must have built-in security firewalls.
• Hardening of the ECUs by deleting all the interfaces and services that can be potential entry-points for the attackers is a must.
• Cybersecurity guidelines should be followed during unit testing, integration testing and system testing of hardware and software modules.

A Brief Overview of ISO/SAE DIS 21434

Discussion on automotive cybersecurity is incomplete without the mention of ISO/SAE DIS 21434 standard. Similar to ISO 26262 in structure and scope, this standard covers the cybersecurity engineering aspects for road vehicles.

The standard was first published in the year 2016 by the joint effort of ISO and SAE. The aim of this standard is to provide guidelines on how to manage automotive cybersecurity, similar to how ISO 26262 standard manages the Functional Safety for road vehicles.

A Snapshot of ISO/SAE DIS 21434 standard:

• Cybersecurity Management: This deals with the goals and objectives of cybersecurity management such as defining the objectives, strategies, establishing a cybersecurity culture and so on.
• Methods for Risk Assessment: This part showcases the methods to assess the risks associated with assets. Vulnerability and attack analysis is performed at this stage.
• Concept Phase: At this stage, the exposure to cybersecurity risk is determined for a specific automotive component. Goals are defined to reduce the risks.
• Product Development: This is a reference for cybersecurity guidelines to be followed during system, software and hardware design.
• Supporting Processes: This section enlists the management systems to support the activities undertaken to achieve cybersecurity. Cybersecurity Assurance Level (CAL) classification scheme is introduced here. It is essentially a measure of how rigorous cybersecurity requirements should be for a particular item. It is similar to ASIL in ISO 26262.

Final Thoughts

Cybersecurity is now a priority for automotive OEMs and other stakeholders, and rightly so. It is also seen as one of the quality aspects of a vehicle, given the fact that automobiles are more connected than they ever were. It will be interesting to see how the industry addresses the pain points related to cybersecurity in the coming years.

Linux OS Porting Best Practices for Embedded Systems

Linux is an exceedingly versatile operating system that has been deployed in a wide range of devices – large and small. It supports a huge variety of chip architectures and has hence, found utility in data centers of large enterprises, connected devices powered by the Internet of Things (IoT), personal systems and consumer electronics.

For embedded system development, there are several popular choices for operating systems. And over the years, Linux has evolved to be one of the most preferred operating systems for embedded applications.

In this article, we explore the many advantages of using Linux for embedded systems and some of the best practices to follow while developing Linux based IoT applications.

Advantages of Linux over Other OS

The widespread popularity of Linux arises from the following benefits it offers for embedded application development:

• Open Source –Linux is open source and royalty-free. It should be noted that there are several costs associated with configuring it to develop full-fledged embedded applications. However, the fact that open source Linux enables easy bug fixes (without having to approach a vendor), makes it an attractive option. Another perk of using Linux is the easy availability of features and add-ons developed by the talent pool of an open source community.
• Extensive Support – Linux supports almost all libraries, tools, and programming languages for embedded systems. It provides a web server, communication protocols for USB devices, graphical toolkit, and much more! An important point to note here is that Linux also supports a wide range of hardware platforms (SoC, SoM, etc.). You may, however, have to develop specific Linux drivers to support custom hardware. But this feat can also be accomplished effortlessly with Linux.
• Standards – The Linux OS adheres to several standards, including BSD, POSIX, FHS, etc. You can easily migrate to other operating systems, in case there is a need to do so.
• Quick Booting – When compared to other leading operating systems for embedded applications, Linux has a quick boot time and smaller footprint. In some use cases, the multitude of features offered by an OS such as Android is not needed at all. In this scenario, a simple Linux platform can perform the required tasks efficiently.
• Developer Access – Hiring engineers for embedded Linux development is also not a stressful task, as there is a vast community of experienced developers around the world
• Hypervisor – Hypervisor is basically a software that runs virtual machines. Linux has an in-built open source virtualization technology, Kernel-based Virtual Machine (KVM) that enables you to convert Linux into a hypervisor. This facilitates a host system to run multiple individual virtual environments called guests, on a single workstation. Large enterprises can benefit from these virtual environments as they simplify resource administration and streamline operations.

Choosing the Right Version of Linux

The ready-to-deploy Enterprise version of Linux is not considered to be suitable for embedded systems. So, embedded system developers tend to create their own customized versions. This is usually referred to as Roll-Your-Own (RYO) Linux.

An embedded system engineer can select just the relevant components from the community distribution for their specific use case. Then, they can add features to the stripped-down version of Linux, based on their requirements.

RYO Linux, however, is not suitable for embedded systems with low-resource environments or low-end hardware, i.e., hardware that is underpowered to execute multiple tasks with a scheduler.

Commercially supported Linux for embedded applications is similar to off-the-shelf Enterprise Linux in many ways. Commercially supported Linux has a compact core that supports low-resource environments effectively. This core framework is offered by Yocto Project and Open Embedded communities. This version of Linux is cost-effective and offers long-term support/maintenance and faster time to market.

When designing an embedded system application, it is crucial to analyse the Linux OS options available and decide on a suitable framework.

Best Practices for Linux OS Porting Projects

Listed below are some best practices that should be followed by embedded system engineers while undertaking a Linux porting project.

1. Hardware Requirements – The first step is to identify the type of hardware to be used for the application. Decide on the type of processor and interfaces to be incorporated. For instance, if Linux OS porting is done for an automotive application, it is imperative that the CAN interface is included. There is also a need to assess the memory requirements.

   The decision on the type of hardware, RAM and interfaces predominantly depends on the project BOM cost and associated criteria.

2. HMI Components – HMI components run in the application layer and interact with the hardware. Linux requires HMI components that offer rich GUI features. It is necessary to employ third-party products to build a hardware- and OS-agnostic user interface for Linux based applications. Product offerings from Elektrobit, Qt, CGI Studio and OpenGL are widely used for HMI development in the industry.

   There are products that provide customized GUIs with 2D and 3D support, effects and animations, specifically suited for automotive applications as well.

   The HMI can be configured to have basic or advanced features, depending on the use case. The user interface design should also include all elements required by the operator and eliminate the ones that are not needed. The system efficiency pivots around the layout of the GUI, the size of the buttons and the navigation loops. It is imperative that an easy-to-use navigation menu is in place so that the operator can access the critical functions quickly.

3. Security Considerations – Security aspects at the hardware and software level should be given due attention while developing connected devices. Technologies such as Trust Execution Environment (TEE) help address security issues for embedded systems.

   TEE is a secure spot inside a processor in an isolated environment. This runs in parallel to the OS and ensures that the code and data in the TEE are secure, with respect to integrity and confidentiality. Applications that run in the TEE can access the main processor and memory of the device. However, hardware and software isolations protect the various contained applications from each other.

   Some of the hardware technologies that support TEE implementations are:

   • SGX from Intel
   • TrustZone from ARM

   ARM TrustZone facilitates embedded system security starting at the hardware level, by enabling two environments to run together on a single core – a secure and a non-secure world. The non-secure software is blocked from accessing the resources in the secure world.

   Another concept is Secure Boot, a process in which the operating system boot images and code are verified against the hardware before being used in the actual booting process. The hardware is pre-configured to authenticate code using trusted security credentials.

4. Library and API Development – APIs are developed to enable various peripheral functionalities. For instance, lighting up a part of the application’s GUI can be accomplished through an API.

   Generic API development that does not restrict porting of the application across multiple platforms should be considered seriously. Similarly, software library development for various functionalities should also be analyzed during the design phase.

5. Device Tree (DT) – It is recommended to use a hardware discovery solution such as Device Tree in Linux applications. DT is essentially a data structure and language that describes the hardware and can be read by an operating system. Usage of DT ensures that there is no need to hard code machine details in the program. Linux OS uses DT data to find and register the various devices in the system.

   The device tree images can be statistically passed to the kernel at boot time. It can also be expanded to a kernel internal data structure for easy access after system booting.

6. Board Bring-up – Board bring-up is a planned activity in which the embedded electronics application (including hardware, firmware, assembly and low-level software elements) are tested and validated in an iterative manner to ensure readiness for manufacturing. This activity consists of a set of repeatable steps that will be performed on a prototype to ensure that all functionalities are working as expected.

   The main phases in a board bring-up activity includes:

   • Checking if the board has been assembled accurately
   • Testing of the hardware
   • Testing firmware and low-level software
   • Evaluating memory and signal integrity
   • Loading OS and checking embedded software

   There should be adequate planning for board bring-up activities during the initial phases of the product development life cycle.

7. Boot Time Optimization – Boot time is basically the sequence of steps a system performs from the time it is switched on till it is ready to be used (after loading of applications). Boot sequence follows several steps.

   Complex embedded systems based on Linux, Android or Windows may have long boot times that can adversely affect user experience. With increase in complexity of devices, several new challenges arise in getting these applications to boot-up quickly.

   However, it is possible to optimize boot time significantly through methods such as cold boot optimization, suspend and resume, and hibernation boot-up. The selection of an appropriate boot time optimization method depends on the application itself, the underlying platform and the use case.

8. Power Management – The overall power management of a device depends on two criteria – power consumption while the device is idle and while it is being used. Power management can be efficiently performed through software techniques and hardware techniques.

   Software power management techniques should be considered during the design phase itself. Power measurement and analysis can be performed using third-party software such as PowerScope.

   Hardware power management can be classified into two types – static and dynamic. Static power management (SPM) is done during the design phase and this is used for optimization of both hardware and software. Dynamic power management uses runtime behavioural changes to minimize power consumption.

9. Testing and Validation – This involves the creation of testing frameworks for the validation of BSP, APIs, libraries, interfaces, hardware, etc. It is advisable to incorporate a Validation and Verification (V&V) methodology early in the development phase itself. This ensures that errors are detected and eliminated in the early stages and hence, resolution costs are minimized.

Conclusion

One of the quickest ways to build components for an IoT ecosystem is by using embedded Linux. You can enhance the capabilities of existing connected devices or design a new system from scratch, without too many hassles. Linux has the power to future-proof and also provide IP gateway services for an IoT infrastructure. Following the best practices listed above, it is possible to build a robust IoT application through Linux OS porting.

Technology for Telemedicine – A Detailed Guide on Enabling Telemedicine Through IoT

e-Health is a conspicuous buzzword in the healthcare industry today. It is essentially the use of communication technologies and data transfer for the delivery of remote healthcare.

eHealth is still in its nascent stages as far as adoption is concerned. Nevertheless, it carries great promises such as improved efficiency in healthcare, enhanced quality and cost reduction, empowerment of patients, and extension of healthcare beyond the current boundaries it is restricted to.

e-Health is a combination of diverse services such as e-learning, health informatics and telemedicine, to name a few. In this article, we explore how the Internet of Things (IoT) can provide a robust technology framework for enabling telemedicine.

An Overview of Telemedicine Services

Telemedicine can be defined as the delivery of healthcare services by professionals using various technologies. This mitigates the limitations of distance, as information related to diagnosis, treatment, prevention of ailments, etc. is exchanged between the doctor and the patient through electronic means.

The main advantage of telemedicine is its ability to bring health services closer to patients living in remote locations where it is otherwise difficult to obtain quality healthcare. In the recent years, telemedicine is found to improve the efficiency of healthcare services, as it enables sharing of resources (medical consultations and patient health records) across multiple remote locations.

Some of the services included in telemedicine are:

• Remote assistance for teleconsultations, diagnosis, follow-up checks and continuous treatment plans.
• Hospital administrative services such as laboratory testing, billing, resolution of issues, etc.
• Telemonitoring is the usage of technology to transmit patient data between individuals in geographically different locations. This helps both doctors and primary caregivers monitor patients through electronic devices. Telemonitoring services facilitate continued care of patients at home. This reduces hospital stays and also provides them more control over the management of their diseases.

What are the Main Applications of Telemedicine?

As indicated above, telemedicine is applied in remote patient healthcare. Patients who are unable to travel to hospitals or those residing in remote locations without quality healthcare institutions find immense benefit from it. It is also considered by patients who seek second opinions for their medical diagnoses.

Telemedicine, a salient example of IoT in healthcare, facilitates the exchange of a wide range of information between doctors and patients through connected devices and the internet. This includes:

• Diagnostic x-ray images
• Clinical laboratory data or patient history details
• Diagnosis of cardiovascular diseases
• Tele-dermatology image transmission and video conference

Challenges in Implementation of Telemedicine

Some of the common challenges encountered while trying to implement a telemedicine service can be summarized as follows:

• Stakeholder engagement – It is found that people are, more often than not, resistant to a change in the conventional mode of providing/obtaining healthcare services. The absence of an emotional bond formation between the healthcare expert and patient and unfamiliarity with the advancements in eHealth technology are some factors that contribute to this resistance.
• Organizational limitations – In order to implement a telemedicine model, it is necessary to redesign the existing models in healthcare organizations. There may also be a need to redefine roles and responsibilities. Implementation costs and funding needs are other factors that fall under this category.
• Technological factors – It is found that the lack of infrastructure and skills for managing the technology for telemedicine is a key barrier to its implementation. In this context, it is important for healthcare organizations to collaborate with a reliable IoT partner company with experience in the domain.

Apart from the above factors, it is crucial to establish a well-defined evaluation methodology for the deployment. The actual deployment results may differ from the research findings of the past. Hence, the deployment should be considered as an iterative activity wherein the outcomes of each stage may result in further process flow changes.

Framework for Implementation of Technology for Telemedicine

When we scan through the challenges listed above, we find that technological factors are a crucial deterrent in the implementation of a telemedicine framework. In the recent past, the advent of cost-effective web and mobile applications have accelerated the growth of remote healthcare.

Ideally, telemedicine technology should be user-friendly, available, and customizable. In other words, the hardware of devices should have a streamlined form factor that appeals to the patients and healthcare professionals alike.

The technology should also be easy to integrate with the existing healthcare infrastructure. Another aspect to be considered is the training that needs to be imparted to users for smooth functioning of the setup.

Healthcare organizations can leverage the power of IoT to develop telemedicine applications that are robust, cost-effective and available. In the implementation of a telemedicine framework based on IoT, the following components play a significant role:

1. Healthcare devices – Examples of IoT-enabled healthcare devices are wearable health monitoring apps used by patients. These healthcare devices monitor the vitals of the user and record data over a period of time. Some of these devices can also assist in prediction of impending diseases based on the overall health of the user.

Patient monitoring is not the only purpose of deploying an IoT-powered device. Hospitals may install IoT sensors on wheelchairs, nebulizers, defibrillators and other medical equipment so that these can be tracked in real time. The location of medical practitioners associated with the hospital can also be monitored this way.

2. Cloud application – The data collected by healthcare devices may be sent to an IoT cloud platform from where the information is consolidated by the healthcare provider. This data can subsequently be transmitted to IoT applications used by healthcare facilities for patient monitoring purposes. This information yields valuable insights for the future treatment of patients.

IoT-based telemedicine app development

Telemedicine apps can be segregated into the following types:

1. Synchronous telemedicine apps – Also referred to as interactive telemedicine systems, these applications provide real-time interactions between doctors and patients through telecommunications. The live conferencing feature in these apps helps in sharing the patient’s ailments and conditions effectively, hence facilitating improved level of interactions.
   

2. Asynchronous telemedicine apps – These apps collect the patient’s medical images and records and share with the doctor/healthcare facility at a suitable time for analysis. The collection of data can be done by a primary care provider if the patient is unable to do so himself. These apps do not mandate the simultaneous attention of both parties for the consultation.
   

Applications for remote monitoring of patients – Remote patient monitoring or telemonitoring is usually utilized for keeping track of the health conditions of elderly patients. Patients use devices fitted with sensors that transmit signals through the cloud application/server. The doctor and primary care providers can monitor the signals from patients remotely through the telemedicine app.

Mobile Health applications – The concept of Mobile Health (M-Health) includes smart mobile applications that transmit data through powerful mobile data network. The doctor and patient can access the medical records asynchronously.

Key Requirements for the Successful Deployment of a Telemedicine App

• Device and network selection – Selection of the right type of device hardware, network connectivity and communication protocols are vital in determining the most suitable telemedicine app for your requirements. While deciding on the hardware, security in data transmission and storage needs special focus.
• Rigorous testing before implementation – It is important to elaborately test the telemedicine app before launch, as it would otherwise incur unplanned logistic expenses.
• Predictive maintenance – IoT-powered telemedicine infrastructure can be fortified with predictive maintenance capabilities to minimize downtime and improve efficiency.

Basic Features of a Telemedicine App

A telemedicine app should have the following features to cater to the needs of patients:

• Easy registration
• Concise patient profile
• Search functionality to connect to suitable physicians
• Communication (audio, video, text chat) facility
• Payment gateway
• Appointments and notifications
• Review and rating
• Emergency call facility
• Insurance module

As far as the healthcare provider is concerned, the following features would be beneficial in a telemedicine app:

• Concise doctor profile
• Calendar and schedules
• Patient tracking
• Prescription management
• Dashboards showing status of treatments
• Data storage in cloud
• Video/audio session recording
• Pharmacy stock details

Concluding thoughts

Telemedicine has evolved to be a promising healthcare service that provides several benefits to both the doctors and patients. Apart from facilitating easy availability of quality healthcare, it offers an amplified degree of convenience for patients. Medical record keeping and unified patient monitoring features make this solution extremely useful for physicians and administrative staff alike. Telemedicine apps also aid doctors in efficiently managing their time.

Considering the extensive range of benefits offered by this technology, it is expected to bring about a paradigm shift in the future of healthcare! Watch this space for more insights on eHealth and telemedicine.

How SOME/IP Enables Service Oriented Architecture in the New Age ECU Network

The rising demand for bandwidth has led the Automotive industry to think beyond CAN, FlexRay and even MOST. We are talking about applications like Infotainment, ADAS, highly automated driving and over-the-air update (OTA). All of these new age automotive solutions need lightning fast data transfer speed to the tune of 100 Mbps. Moreover, a paradigm shift from the existing signal-based communication (CAN, LIN) to service-based communication is something that can make a difference.

Ethernet emerged as the best fit considering the changing communication requirements of the ECU both within the vehicle and beyond. As an industry-wide accepted protocol, Ethernet is backed by over 30 years of rigorous R&D and proven protocols such as TCP/IP and UDP. However, Ethernet could not be used as it is, in the automotive industry.

There are certain add-ons that are required to make it compatible with the communication demands of an automotive ECU. One such pre-requisite, that we briefly mentioned above is the implementation of service-oriented architecture (SOA). And that’s where SOME/IP (Service-oriented Middleware over IP) takes the center stage.

But before we go into the nuances of SOME/IP, it is recommended we understand the service-oriented communication in contrast to the signal-based communication.

Signal-Based Communication vs Service-Oriented Architecture

Signal-based communication has long been used in communication protocols such as CAN, LIN, FlexRay, MOST and more. As the software and hardware in such automotive solutions are closely coupled, the communication between the ECUs are defined statically. It is assumed that the software will not be modified during its lifetime. Signal based communication was best suited for such applications.

In the realm of Signal-based communication, the data is sent over the network whenever the data values are updated or modified. The sender is not concerned about whether the data is required by a node in the network. Such an arrangement may burden the nodes with unwanted data that they might never require.

Fast forward to Service-oriented architecture, the sender sends the data only if a receiver needs it. Therefore, in such an arrangement, the server has to be notified about the receivers that are waiting for the data. This is merely one aspect of the service-based communication.

When we talk of highly automated driving, ADAS, connected cars, etc., service-oriented architecture (SOA) is a must-have. Powered by Ethernet and SOME/IP, SOA models the entire system as service interfaces. New software can be easily added to the system without worrying about the compatibility with others.

While Ethernet provided the backbone and TCP & UDP the transport layer, a middleware was required for data serialization, remote call procedure, etc. And that’s precisely why SOME/IP was created!

What is SOME/IP?

SOME/IP stands for Scalable Service-Oriented Middleware over IP and was developed by BMW group in the year 2011.  The name makes it abundantly clear that it is a middleware solution that enables service-oriented communication between the control units. More specifically, SOME/IP offers a wide range of middleware features like serialization and Remote Procedure Call (RPC) to enable the ECU software to communicate with each other.

SOME/IP can be implemented on both OS (Genivi, AUTOSAR, Linux and OSEK) and Non-OS embedded system. In the recent past, it has emerged as the middleware of choice for Adaptive AUTOSAR implementation.

As already mentioned, the service-oriented architecture makes it easier for the software components over diverse networks to communicate with each other. Therefore, in order for these applications on different networks to understand each other, there has to be some kind of a middleware. Its primary role is to resolve the message format and make it comprehendible to the intended recipient of the message. SOME/IP has been specifically designed for this purpose.

So how does SOME/IP resolve the different data packets and makes the inter-ECU communication possible? Let’s find out!

Some Key Features of SOME/IP:

1. Serialization: It is the way the data is represented in a data unit, which can be either a UDP or a TCP message. When data is transmitted over network, the ECU reading the data might have a different architecture, operating system, etc. Inoperability can be ensured only if there is a mechanism for a consistent data transmission. SOME/IP allows for some serialization.
2. Remote Procedure Call (RPC): This is a method for remote invocation of functions as requested by the Client ECU. It is a data exchange method employed by the client ECU when it requires some data from a server. An RPC may or may not have a return value, i.e., the client can ask for data as a response or simply call a function to perform some task at the server-end.
3. Service Discovery: The service discovery (SD) protocol is the backbone of SOME/IP concept. In a service-oriented architecture, it is imperative for the service (functional entity- methods, events or fields) to be discoverable. The SOME/IP SD protocol manages this aspect- whether to offer a service or stop it from being available.
4. Publish/Subscribe: A client can subscribe to the content of the server so that it can receive the updated data from the server dynamically. Publish/subscribe feature of SOME/IP deduces which data (event/field) a client needs and shares the same. Pub/Sub is managed by SOME/IP SD.

So far, we have understood the concept of service-oriented architecture and the role of SOME/IP in its implementation. We will now delve a little deeper to understand how exactly SOME/IP and Ethernet enable the inter-ECU Client/Server communication.

Understanding how Communication through Ethernet and SOME/IP Works

Before we start with our exploration, we must understand some terms associated with SOME/IP.

The Server ECU provides a service instance which implements a service interface. The client ECU can use this service instance using SOME/IP to request the required data from the server. The Service Discovery protocol has two mechanisms in place by which a client knows about the available services.

The first mechanism is the ‘Offer Service’ using which the server is able to provide the available services to the network. The other one is ‘Find Service’, which enables the clients to request for the available services.

However, in order for the client to use the service, it has to subscribe to the content on server first.

Using the SOME/IP Service Discovery protocol, a client can send a Subscribe Eventgroup to the server. If the subscription request is valid, the server will respond with a positive acknowledgement and vice-versa.

As the applications inside the ECUs are not tightly coupled in a Service-oriented architecture, multiple clients can subscribe to a service on the server simultaneously. The data can be made available either over UDP or TCP. In case of UDP, data is sent to all the clients who are active subscribers. The data transfer is usually sent via unicast, multicast or broadcast. However, with TCP, the requesting client must establish a connection with the server for data transfer.

While the underlying principle of SOME/IP is based on the client-server architecture where a request by a client is followed by a response from the server, there are several methods/communication patterns for the communication. Let’s have a look at them.

1. Request/Response Method
   • A request is a message sent from the client to the server for calling a function.
   • Response is the message sent from the server to the client depicting the result of the function invoked by the client
   
2. Fire and Forget Method
   • A message is sent to the server from the client to call a function
   • No response is returned from the server
   
3. Services: Event
   • An event is a callback sent from the server to the client either cyclically or when a change in the server attributes occur
   • The server notifies about the change only to those clients who have previously subscribed
   • A notification of event is sent to the client every time the event occurs
   
4. Services: Field
   • Field is a property of service that can be remotely accessed using Getters/setters.
   • Getter is the method to read field value
   • Setter is the method to set the field value
   • When a field’s value changes, a notification event is sent out by the notifier.
   

Value-Adds of SOME/IP as an Inter-ECU Communication Protocol

The fact that SOME/IP enables service-oriented architecture itself adds a lot of value. Not only does it make the entire vehicle network dynamic and flexible, but also provides the backbone required for implementation of CPU-intensive applications.

Let’s check out some more advantages that SOME/IP brings to the table:

• Adding new functions to a vehicle electronics system becomes easier
• Provides the required flexibility to the vehicle system as part of a connected ecosystem
• Complicated service interfaces can be implemented using Ethernet with the help of events and methods
• It supports both unicast and multicast.
• It reduces the complexity of the data path by introducing events, notifiers, etc.

The Bigger Picture

SOME/IP is a masterfully crafted middleware with features of CAN, MOST and FlexRay along with the coveted service-oriented communication. Its liaison with another path-breaking technology- Adaptive AUTOSAR, is already grabbing eyeballs. Together, they have the potential to change the way automotive software is developed and integrated to the ECU network.