Challenges of implementing SOA

*Author: coroutines

Preface:

It’s been about 20 years since the emergence of SOA. I remember there used to be Web Service, which could be deployed on WebSphere (not sure how it is now, seems to be in the hands of IBM?). And there was J2EE, designed for services based on EJB. Since switching to embedded systems, I haven’t paid much attention to these things. However, due to the automotive field being the largest embedded system, the inevitable introduction of mature business models in recent years will restructure the automotive field. The current trend shows that service-oriented architecture for automotive applications is unavoidable and will become the trend for the next few years. Therefore, this article summarizes some basic concepts of SoA and discusses how to introduce SoA in the automotive field.

Current situation in the automotive field

Let’s start with a process chart of BMW:

The traditional development process starts with the customer’s requirements. After selecting the supplier, the customer’s requirements need to be standardized (Specify), because most of the original requirements may not be clear or specific. Especially for these large factories, that integrate numerous ECUs, there are almost no specific requirements for certain ECUs at the beginning. I have encountered input requirements like this from two European and one Japanese car factories.

Next, the system architect analyzes the requirements, reaches an agreement with the customer on the requirement’s understanding (including functional safety requirements and information security requirements), and enters the system architecture design process, which is the descending part of the V model. During this process, each company’s methods may differ, including different periods of the same company, different projects may be different, such as considering the static and dynamic parts of the system architecture, some use SysML, some use Visio, some use Word, and the Japanese like to use Excel. The system architecture design outputs the main logical components of the system, analyzes various requirements onto the components, including functional and non-functional requirements, and then enters the software and hardware architecture design stage. Software architecture design may use UML, and the design of the system’s static structure based on AUTOSAR also uses related AUTOSAR tools.

If the designed SWC is used for signal processing or algorithms, Simulink can be used directly for modeling and development, which is the unit design phase. Of course, you can also write the Runnable in SWC manually. Next, it is the upward phase of the V-model, unit testing (MIL, SIL, HIL), integration testing, and system testing. We can refer to the detailed process model of ASPICE and ISO 26262, which need to consider the traceability and consistency issues throughout the development process.## Several Issues Encountered in Current In-Vehicle Processes

Several issues encountered in the field of in-vehicle electronics are summarized as follows:

2.1 Function Division

Traditional in-vehicle electronics functionality division is mainly based on the calculation capability of the ECU. For example, an ECU designed for instrument cluster cannot handle IVI tasks, and the GPU capability of IVI may even be inferior to that of the instrument cluster after upgrading to a fully LCD display instrument cluster. Although the cabin system saves some resources in hardware, the cost savings are basically offset by the software development costs. In addition, there are many other independent ECUs in the vehicle, which greatly increase the development cost due to separate wiring (power supply, communication, sensor and driver, etc.). Currently, ECUs tend to have high integration, therefore, the re-division of each function and its flexibility and replaceability in the future vehicle body need to be carefully considered.

2.2 Universal ECU Requirements

As mentioned earlier, each OEM usually provides universal ECU requirements. This saves time in writing requirements, but introduces the problem that suppliers sometimes cannot figure out which requirements to implement and which not to, leading to over-design of the final ECU.

2.3 Project-specific or Supplier-specific Development Methods

Specific projects and suppliers may adopt different process models and development methods, which increases the difficulty of managing deliverables.

2.4 ECU-specific Optimization

Suppliers often can only see the parts they are responsible for when designing the ECU, which makes specific optimizations insufficient to meet the non-functional indicators of the entire vehicle, requiring global coordination.

2.5 Introduction of High-performance Processors

Currently, high-frequency, multi-core and heterogeneous processors are gradually increasing. In addition to the built-in high-performance GPU and visual processors, high-performance real-time cores are also added to the SoC, which further increases the integration of the SoC. The previous double-chip architecture of IVI or instrument cluster is gradually being replaced by a single-chip, which also reduces the cost. However, how to utilize high-performance processors is a new issue.

2.6 Lack of Calculable Architecture ModelThe problem arises during the integration testing stage of the entire system or vehicle in the automotive industry. Typically, the design process has already been completed, and the product has entered the testing stage. However, some potential problems in the design process can only be identified during this stage. For example, delays in the vehicle’s network, bandwidth usage, delays in ECU internal messages and random events, and CPU usage. The languages used in the design process, such as SysML and UML, lack simulation capabilities, which may result in these issues not being identified during the design process.

Challenges in implementing SOA

The challenges of implementing SOA can be summarized as follows:

• How to implement agility, flexibility, and strategic reuse of assets when collaborating across departments.
• How to improve delivery efficiency and reduce costs when introducing these capabilities.
• How to effectively integrate and utilize existing assets or data in distributed development to achieve faster delivery.
• How SOA’s agility and flexibility can help achieve business goals.

The challenges of SOA can be summarized by the following image:

First of all, is reuse really happening? In my personal experience, reuse in embedded system architecture or multimedia middleware is a reality that has occurred. However, these are mostly based on experience and the abstraction of some technologies, which can be applied in small systems or subsystems and can indeed have a good effect. Can the same approach be taken for services? After all, I have separated the parts that are easily changed in the system and placed them outside. The reuse of services does not depend on what technology is adopted. The main obstacles are organizational, methodological, and policy-related issues. Therefore, with regards to reuse, there are the following requirements on the architectural platform:

• Service consumers can publish, search, evaluate services, and register as users.
• The architecture is capable of managing and maintaining the lifecycle of services.
• Able to ensure quality and the lifecycle of specified versions of services.
• Consumers can decouple their association with the lifecycle of services.

Efficient development means completing as many functionalities as possible in as short a time as possible and with the least cost. Achieving this goal depends on various factors, including reusing existing services and quickly building applications based on these services.For some teams or organizations, introducing different development methods can be more convenient to achieve this goal. For example, by introducing clearly defined process models (such as ASPICE), it is convenient for relevant personnel to find basic information related to the necessary services; or using new system design methodologies (such as MBSE), focusing on building business models, rather than focusing too much attention on the services themselves. Then, through hierarchical decomposition, attention is given to how to implement business models at different levels and scopes.

In MBSE, analytical methods can also be provided to clarify the interactions, interfaces, and decision-making means involved in the implementation of services. In addition, if necessary, it is also necessary to optimize the organizational structure, such as the example of banks mentioned earlier, divided into service users and service providers. For the challenge of efficient development, the technical architecture must meet at least the following requirements:

• Reference architecture to guide service design

• Define business processes for discovering and defining necessary services

• Process model for effectively managing the integrity of services, including service users and providers

Application and data integration is a particularly confusing thing. Old system applications and data may use some point-to-point protocols, such as DBus, ProtoBuf, or some custom RPC/IP protocols (usually with poor maintainability and scalability).

Based on web service-oriented architecture (SoA), some references for data communication implementation are given, but technology only accounts for a small part of SoA, and the key lies in thinking about the business model. For example, point-to-point communication cannot be used again, instead, consider connecting all independent applications/services to the overall business model.

In addition, for the process of exposing interfaces, consideration should also be given to whether the original old interfaces should be used to implement them, or whether the latest technology should be used to update interface implementation. For data integration, the point to be concerned about is not how to define the data structure in the data list, but which data should be shared through the interface, and the definition and maintenance of internal data are managed by the application itself. For integration, the following architectural requirements need to be considered:

• Global data sharing strategy

• Reference model for services used for integration

• Support for converting data from existing systems to new business models

Agility and flexibility can be demonstrated by creating new business models quickly and efficiently using existing services, which requires us to be able to easily find existing functions and data, and to efficiently utilize these functions and data. Consistency requires that business architecture-related information, applications, and technologies can be reflected in the development process. This requires:

• Reference architecture can reflect the business and information-related parts of SoA and their relationships

• Design service interfaces based on common semantics models.- Model-based design methods to ensure traceability between business models and implementation systems

• Process models can ensure and guarantee consistency.

How to address challenges

Creating and maintaining a reference architecture is a key focus in the implementation of service-oriented architecture (SoA) applications. Typically, informal processes make it difficult to ensure success in SoA implementation. The following diagram outlines several important activities and their relationships in the SoA reference model:

Specifically:

• Support business logic, information, application, and related technology required at the organizational level
• Categorize required services, such as business logic, different domain requirements, tool-related or integration-related services
• Apply appropriate SoA methodology
• Separate solution and technology concepts

In the design process, generic design semantics such as SysML and SoaML are used in conjunction with MBSE and MBD methods. The process model is also essential for defining personnel roles, guidelines, templates, checklists, managing development artifacts, and distributing them to relevant personnel.

To address the above issues, the following areas need to be considered:

4.1 Seamless requirements management process

To ensure that customer requirements are correctly implemented, consistency and traceability principles must be strictly adhered to from requirements analysis to architecture design. This is especially important in product designs based on functional and information security. Some projects use ID appended documents (such as Word and Excel) and third-party tools for traceability management, which is primitive. Projects based on the MBSE methodology can use SysML / UML to standardize requirements and architecture design and use design tools to automatically generate traceability matrices and coverage verification, making it suitable for seamless requirements management.

4.2 Overall SoA-based architecture design

Considering the integration of ECUs and the fact that future automotive electronic functions will no longer be divided by ECUs, the flexibility of function deployment needs to be considered. With the introduction of high-bandwidth networks and high-performance processors, it is possible to implement SoA architectures based on service discovery and remote access in the embedded domain. SoA-based applications can be easily integrated into the system ecosystem, and service migration and cancellation are transparent to service users. At the same time, support for traditional network buses such as CAN, Flexray, and Lin can be smoothly compatible, and network topology expansion is also easy to achieve.The automotive system is a whole, and some non-functional requirements, such as performance indicators and safety goals, need to be achieved through the collaboration of the ECU, sensors, and drivers throughout the entire chain. Therefore, considering the performance indicators and optimization strategies of the whole system from the perspective of overall vehicle architecture is an effective method. The flexibility of the SoA deployment can effectively support such architectural adjustments.

In the system architecture stage, if there is a lack of computable models, some performance indicators, resource utilization indicators, etc., cannot be visualized in the architecture design stage. This requires us to consider a feasible architecture simulation method. Based on the DES simulation model, an implementation of architecture simulation can be provided here, where services can be concretized into message processing nodes. The prerequisite is that we need to obtain as realistic inputs as possible through historical data.

4.3 Distributed Development

One advantage of service-oriented architecture is that the requirements assigned to each service are clear, which makes suppliers more aware of what they need to do. To cope with the different development processes of various suppliers, the SAFe model can be considered, which is a large-scale agile implementation method. Based on the agile of the Team level, SAFe adds agile and practices at the Program, Large Solution, Portfolio level, etc. and can meet the OEM unified process, quickly and accurately meet the product requirements.

4.4 Agile Development Process

At the Team level, common agile methods such as Scrum, TDD, Kanban, etc. can be considered. However, regardless of any method, customer participation, such as the role of Product Owner or Function Owner, is needed. For projects involving functional safety and information security, relevant auditors also need to perform necessary audit processes during each iteration of the project development to ensure the quality of the deliverables.

4.5 Continuous Integration and Testing

As a means of agility, continuous integration (CI) is an important technology to ensure project quality. Continuous integration includes automated static code checking, automated unit testing, coverage testing, automated integration testing, interface, and control/data flow coverage testing, etc. For functional safety products, fault injection testing needs to be performed; if it is an information security product, automated fuzz testing needs to be performed, etc. For products developed based on models, MIL/SIL/HIL needs to be added to the unit testing process. These can be considered to be deployed and executed using Jenkins.

This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.