The automotive industry is constantly striving to reduce costs but at the same time introduce new and innovative comfort and convenience features to enhance customer demand. Most, if not all, automotive companies have now adopted various bussing systems to reduce wiring complexity, weight and hence overall costs (plus increase fuel efficiency).
Whilst flexible topologies are ideal, we understand the need for global standards which offer better business cases to suppliers, which would ultimately lead to greater competition and lower prices. J1850 in the US and ubiquitous Bosch defined controller area network (CAN) in Europe have been the most popular standards to date but in some applications can be considered "over kill". Hence the local interconnect network (LIN) was born for low end, low speed applications. This network complements CAN for medium speed, media oriented systems transport, (MOST) for the high-speed data rates and FlexRay, for safety-critical applications such as steer- and brake-by-wire. Figure 1 shows the relative cost per node and speed of the various automotive networks.
Conceived in 1998, the LIN consortium comprises car manufacturers Audi, BMW, DaimlerChrysler, Volvo and VW. LIN is an inexpensive serial bus used for distributed body control electronic systems in vehicles. It enables effective communication for smart sensors and actuators where the bandwidth and versatility of CAN is not required. Typical applications are door control (window lift, lock and mirror control), seats, climate regulation, lighting and rain sensors. Outside the automotive sector LIN is used for machine control as a sub-bus for CAN.
Figure 1: Relative cost per node of automotive networks.LIN is a UART-based, single-master, multiple-slave networking architecture originally developed for automotive sensor and actuator networking applications. The LIN master node connects the LIN network with higher-level networks, like CAN, extending the benefits of networking all the way to the individual sensors and actuators.
Typical applications for the LIN bus are assembly units such as doors, steering wheel, seats, climate regulation, lighting, rain sensor, or alternator. In these units the cost sensitive nature of LIN enables the introduction of mechatronic elements such as smart sensors, actuators, or illumination. They can be easily connected to the car network and become accessible to all types of diagnostics and services.
The commonly used analog coding of signals will be replaced by digital signals, leading to an optimized wiring harness.
A LIN network comprises one master node and one or more slave nodes. All nodes include a slave communication task that is split in to a transmit and a receive task, while the master node includes an additional master transmit task. The communication in an active LIN network is always initiated by the master task: the master sends out a message header which comprises the synchronization break, the synchronization byte, and the message identifier.
Flexible LIN solutionProgrammable logic has long been accepted as an effective way to bring designs to market quickly and also allow design flexibility right up to production and beyond. This time to market advantage and flexibility historically has had to be balanced with higher component costs. Times have changed and PLDs have become dramatically lower in cost and able to be used in high volume, cost sensitive applications such as mobile phones, PDAs and automotive infotainment systems.
To enable designs to be brought to market quicker and risk free companies like Intelliga have developed robust and fully verified IP Cores aimed at FPGA and CPLD architectures. One example is their LIN core which occupies a fraction of a low cost FPGA (for example 13 percent of a 200,000 system gate low cost FPGA) thus leaving space for further LIN nodes, CAN nodes, UARTs, soft core processors or simply glue logic. In real cost terms the LIN interface whether implemented in programmable logic, ASIC or ASSP is approximately half the cost of a CAN node.
LIN bus cost benefitsThe LIN bus is cost driven and as such this solution is significantly cheaper than CAN. The reliability of LIN is high, but does not have to meet the same level as CAN. LIN bus is designed to be a logical extension to CAN. It is scalable and lowers the cost of satellite nodes and no crystal or resonator is required, it is easy to implement, has a low reaction time (100ms max), and a predictable worst case timing.
Table 1: Relative merits of LIN versus CANThe LIN bus can be implemented using just a single wire versus CAN which needs two wires. This means that a LIN network can also be lower in cost through simpler connectors and wiring (thus also reducing the weight of wiring and increasing fuel efficiency and reducing handling time and costs in manufacturing). CAN also needs a 5V supply for the bus whereas LIN only requires 2V minimum high level. Table 1 shows the relative merits of LIN versus CAN.
We will look at each way in turn and explore the benefits and pit falls of each.
Software: Bit bashingA LIN node can be implemented in many microcontrollers (MCUs) with no additional hardware except for a physical layer driver device. It can be implemented using existing on-chip MCU resources such as timers, GPIO and interrupts- effectively "bit bashing". This type of implementation does, however, have restrictions in that designers must adhere to strict real time programming constraints to meet the full LIN specification plus this will be expensive with respect to MCU timing and on-chip resources and leaves very little bandwidth for other application code. LIN nodes based purely on "bit bashing" may be complicated to test, particularly when integrated with existing RTOS's. Overall with this type of implementation it will be very difficult to achieve accurate bit timing measurement and control and may not be power efficient and overall not really practical.
Software: UART implementationLIN was originally conceived to make use of existing UARTs within standard MCUs plus the uses of on-chip timers, GPIO, interrupts and serial ports. This is a better way of implementing can than simply "bit bashing" but may have certain limitations in designs that already use the on-chip serial port for other tasks. This implementation may also burden the application code with LIN protocol requirements and will complicate design the testability of the code. This method also needs to be complimented with GPIO functionality for error checking and synchronization purposes and requires CPU activity throughout LIN message exchange and therefore is not the most power efficient solution.
Hardware: MCU with dedicated LIN portAn MCU with dedicated LIN port may appeal to more designers as it uses off-the-shelf verified silicon and will not burden the software application with LIN protocol processing as shown in the previous examples. This type of micro is well suited to CAN to LIN bus bridging applications where there is a need to pass data between the two networks. This implementation also tends to be less power hungry than the equivalent software solution.
As with most emerging networks, however, the availability of silicon and relatively high cost may be an issue and suffer from long lead times-so forward planning is a must with respect to ordering devices. One of the potential down falls of using these devices is where more than one LIN is needed, for example in an ECU gateway, this may mean using more than one MCU which will impact part cost, manufacturing costs, PCB complexity and stocking costs.
If your design requires something outside of the specification provided by the silicon vendor this may also cause issues as these fixed function parts allow little or no flexibility to customize. These devices still require and external bus transceiver chip and still requires a degree of real time processing in the MCU. Distributed MCU solutions can result in complex design and test issues associated with software-based designs and the need to explore all potential fault and interrupt loop states so that no strange indeterminate states occur. Exhaustive testing is, however, costly and the test vectors take longer to write than the design code itself!
Hardware: Programmable logic device (PLD)LIN implemented in programmable logic devices (PLD) offer similar benefits to the LIN implemented in a MCU dedicated hardware peripheral. They do, however, benefit from being implemented in generic devices that are off-the-shelf, low cost and low power. This means that time to market is extremely quick and easy. The LIN implemented in PLD hardware does not suffer from complicated test issues as testing hard is much simply and determinant than software based designs. PLD LIN does not burden the software application with LIN protocol processing and allows for accurate LIN timing control and also requires no crystal oscillator in slave mode thus saving costs, board space and low power consumption. PLDs are generic devices and do not incur NRE charges and can be used across many projects.
One of the key advantages is the ability for the devices to be programmed in-system so changing the hardware from Master to Slave is a breeze. As with the MCU designs the PLD needs an external transceiver device to drive the line. The main down side to using PLDs is that you may not be conversant with the design flow so this may not be your most natural design route-but certainly worth trying. In the more integrated higher-end designs your design will still need some sort of processor support but this can be achieved by using an embedded soft core processor such as MicroBlaze (a low cost 32-bit RISC processor).
LIN system developmentTraditionally automotive designers have been faced with a dilemma when adopting a new bus standard, do you wait for a standard silicon devices or try to develop an ASIC with a semiconductor supplier in advance of a final agreed protocol specification? Some specifications take years to finally be agreed so many semiconductor suppliers are loath to start designing devices before the specification is frozen.
In order to take advantage of new bussing networks in advance of fixed specifications designers are turning to soft IP cores embedded within programmable logic devices. This allows designers to try out new ideas risk free and also add in customized solutions within the bounds of the protocol. This approach also allows cut down versions of the full interface if not all of the features are required-thus saving even more silicon area. Now that programmable logic prices have dramatically lowered in recent years they can even be considered as a viable way of designing production solutions as well as simply using them for prototype builds. A key benefit of having a LIN interface embedded within a programmable logic device in the form of an IP core is that it can be reconfigured remotely to be either a Master or a Slave node thus aiding greatly the test and design phases. Even in field fault diagnosis and vehicle maintenance the ability to make nodes either master may be of benefit.
To reconfigure the node it is simply a matter of erasing the device and re-programming it with a new personality in the case of a non-volatile complex programmable logic device (CPLD). The ability to switch between Master and Slave in the same device means that inventory and stocking costs are reduced plus there is only the need to qualify one device rather than two, thus saving the lengthy device qualification time and cost associated with it. PLDs from Xilinx are offered in the extended temperature range -40 to +125ˇC for automotive applications. PLDs come in two main types the larger field programmable gate arrays (FPGAs) and simpler, low power CPLDs.
SummaryThe LIN bus can be used a cost effective alternative to CAN in low speed automotive and industrial networks. To add even more flexibility to the network the LIN interface can be implemented in reconfigurable logic which is not only low power but can be reconfigured remotely to be either a Master or Slave in the device. The ability to reconfigure the device to be either a Master or Slave node can help with fault diagnosis in the field, test in development and also cut down inventory by only stocking one device. This also cuts down on device qualification time and costs. PLDs from Xilinx are offered in the extended temperature range -40 to +125ˇC for automotive applications.
