Service Oriented Architecture in Automotive

What is service oriented architecture?

Service oriented architecture is a form of SW design where software components are considered as discrete services. This allows software to be reusable and use service interfaces to communicate with other services over a network.

As the industry is moving towards giving value of SW feature. Which is really hard with architectures where HW and SW are tightly couple. SoA offers a solution for that. Another driver for this type of architecture is the introduction of high bandwidth data backbones in vehicles. This allows for abstraction to be virtually "hidden" between software applications.

Thanks for reading Autowist! Subscribe for free to receive new posts and support my work.

Principles in SoA

Before going into the details of service oriented architecture, let's look at what are we trying to achieve with this architecture.

• Abstraction: A service is completely defined by it's interfaces and description documents. It encapsulated within it all the necessary functionality.
• Autonomy: Services have control over the logic it encapsulates and manages it's own lifecycle.
• Discoverability: Service discovery enables third-party resources to use services that were not thought of when developing a particular service.
• Composable and Reusable: Services can be used as building blocks that can be further composed to serve more complex functions. Since these are designed as components, they can be re-used multiple times, saving time and cost.

Key components

Services and Roles

A service is a self-contained piece of software that is designed to achieve a specific task. It usually contains code, data and integrations to other services. This level of granularity allows services to be developed, maintained and deployed independently.

• Service Provider Role: Services that provide functionality or data to other services
• Service Consumer Role: Services that consumer functionality or data from other services
• Service Broker Role: Services that allow the communication between services.

NOTE: These roles can be applied to a service as whole and to individual interfaces of one services. For example we could have a service with both provider and consumer interfaces.

Middleware

Typically there are many more layers between the service interface and the communication network. They can include SW middleware, operating systems, Low-level software, network devices etc. Here I treat them all part of the "so-called" middleware.

The primary function of the middleware is to abstract everything between the service itself and the communication network. This is a key enable to have different kind of systems on the same network, but still work together with services elsewhere.

The middleware is also responsible for service discovery. Service discovery enables different services to find each other on the network. This is a key component for services to achieve a level of abstraction between them.

Communication network

The communication network is responsible for ensuring a fast, reliable communication between 2 services. This would include the PHY layer but also some of the layers above it to ensure proper data integrity on both ends of the communication. These days, the network of choice seems to be ethernet.

Design, Implementation And Deployment

The design step involves both the allocation of functionality to services and the design of service interfaces. Together it forms the solution architecture. Development teams then go about implementing the services as per specification

Test and DevOps teams deploy them on various test scenarios, and eventually upon to production environments.

This type of architecture allows teams to organize around each of these steps. Irrespective of if they are following a traditional waterfall model or a more agile way of development

Tools

Managing services on a "global" level is almost impossible without the help of the right tools and integrations in place.

End-to-end modelling is key for enabling and testing service oriented architecture at scale. Use of standard modelling languages like UML and SysML improves the readability and specifications for this type of architecture.

Dependencies between services can become very clear and accounted for in the design process.