Design For True Plug & Play In Automotive LIN

Typical local interconnect network (LIN) slave developments have many common points. Even though LIN slaves usually are smart actuators/sensors, they normally are developed as electronic control units, or ECUs (Fig. 1). The supplier selects from various microcontroller options one with the appropriate performance and memory size. Based on the OEM specification, the applicable hardware is built around the microcontroller.

1. A typical LIN slave is built around a microcontroller with suitable performance and memory size.

A certified LIN2.x software application programming interface (API) has to be applied to guarantee interoperability. This means that LIN slaves become plug & play on the network side. However, on the application side, required functions are implemented in software. New application software has to be developed for each LIN slave.

Various suppliers end up with different application software on different microcontroller cores. Multiple developments stack up, creating a large demand on suppliers’ engineering resources. Each of these implementations needs to be thoroughly tested, with a risk of software bugs remaining.

Test Coverage

The LIN conformance test only analyzes the LIN physical layer down to the API function. Each new implementation of a LIN slave has to be checked to confirm that the mandatory API support functions have been implemented correctly. As with any software development flow, bugs may appear in the later stages of this flow due to limited test coverage.

Consequently, OEMs demand flash-based microcontrollers, adding additional IC complexity, memory size, and development cost, to allow for fast recovery from bugs. In the LIN standard, as in most OEM implementations, flash reprogramming via the LIN bus had not been foreseen. Therefore, this feature is not standardized and requires significant test resources to be allocated to each different microcontroller type.

The high cost associated with certifying one class of microcontrollers lowers the interest for suppliers to change to cheaper or more effective alternatives, stifling their ability to bring ECUs to market that have better performance or are more price-competitive.

Discrete developments using standard microcontrollers require verification for each new application that the reaction time for LIN messages is maintained. The interrupt load from the application can only influence the LIN communication up to a point where the required response timings are met. This may lead to the specification of a more powerful microcontroller than the application itself actually requires.

A possible solution to guarantee timings is through the use of operating systems, which leads once again to additional demands on the microcontroller resources, processing power, and memory. The alternative is the use of dual-core microcontrollers that split the LIN communication task from the application task on the hardware level.

Communication And Application

Each new LIN development forces some changes in software or hardware to be made and, in doing so, adds to both the system costs and risks involved. This impinges upon the capacity of the LIN bus to offer true plug & play operation. To overcome this issue, we need to consider the commonalities between different applications.

A LIN slave typically consists of:

A communication task that manages the data exchange according to the LIN protocol
An application task that performs the actual function of the slave

Defined in the LIN 2.x specification, the interoperability of the LIN task is ensured through conformance tests as well as additional tests by the vehicle manufacturer. This ensures plug & play on the LIN side, but how does this look on the application side?

To realize standardization here, the slave application should not be considered by itself, but in comparison to applications with very similar demands. Plug & play operation is possible if the applications are standardized and configurable within practical limits.

Standardizing LIN Slave Application Functions

The typical path for LIN slave implementation leads to a software development that can only be used for one specific application. LIN slaves from different suppliers that are executing exactly the same functionality look completely different.

This is the standard practice today. The individual development costs of each unique LIN module implementation have to be recouped over the total volume of units produced. Therefore, LIN may become prohibitively expensive for small volume implementations.

Designers can deal with the requirements of different modules by following a system level approach to LIN slave definition. Melexis has done just that with its MLX80104. This integrated LIN slave offering is configurable for a wide range of switch module applications without the need for software development and requalification (Fig. 2). It combines a LIN transceiver with a built-in voltage regulator plus a LIN handler to present a LIN slave that is certified from both hardware and protocol perspectives.

2. The Melexis MLX80104 integrated LIN slave is configurable for a wide range of switch module applications without the need for software development and requalification.

The MLX80104 employs dual-core microcontroller, which is specifically optimized for handling the LIN protocol task independently from the application task. A handshake protocol synchronizes data exchange between the two tasks. Customer specific data like production date or serial number can be programmed onto a dedicated area of the integrated EEPROM memory.

Conclusion

A LIN slave developed conventionally will result in additional costs being accrued due to the need for software development and testing, as well as slowing the whole development process down. To avoid this, a new LIN slave definition methodology is required. For applications suitable to this approach, the specification should be completed at the vehicle architecture level to fully leverage the benefits of LIN as a low-cost network solution.