Universidad de las Américas Puebla

Department of computing, electronics and mechatronics

Automotive Networks
(LIR4021)

Professor Eduardo López Sánchez

Practice 09 Creation of a LIN Network

Team 8:

Carlos Javier García Castillo 156658

Sergio Zaid Cruz Martínez 156803

Cholula, Puebla.

November 11th
Objective ........................................................................................................................... 3
Summary ........................................................................................................................... 3
Introduction ...................................................................................................................... 3
Process .............................................................................................................................. 5
Results expected ............................................................................................................. 10
Results obtained.............................................................................................................. 10
Theoretical practical comparison .................................................................................... 10
Conclusion ....................................................................................................................... 12
Bibliography .................................................................................................................... 12
Objective

The objective of this project is to make a LIN web in order to be able to communicate

two nodes, the first one should be the master and the second one should be the

slave.

Summary

At first we create the slave node and the master node, we know that we want them

to communicate, as the objective says, but first we should create the messages that

will go around the LIN bus, at this practice the ID won’t have priority as we have been

used to in the CAN protocol, at this practice the schedule will determine the time that

the nodes will communicate. All this information will be explained at the Introduction

part.

Introduction

The most important part in this practice are the messages, at LIN protocol the

messages are divided into two parts: header and content. The heading can only be

written by the master command unit and the content can be written by both a master

command unit and a slave unit. The content is written by the master command unit

when in the message the slave units are ordered to use the data contained in the

response, which is transmitted by the master unit itself. The slave units write the part

corresponding to the content in the messages where the header of the same requires

that some of them transmit a specific data. The message is initially divided into two

parts: header and content or response. The content is further subdivided into several

fields: synchronization pause, synchronization limitation, synchronization field and

identification field. In the response or content field, bits written by the slave control

units appear as a "fill-in" of the part of the message dedicated for this purpose. In

this way the slave control unit incorporates the data required by the master unit to

the message.

The synchronization pauses, transmitted with dominant values, is a 13-bit

space that clearly indicates the start of a message. The synchronization limitation

has a minimum length of one recessive bit.

The synchronization field allows all the control units to work simultaneously

and synchronously, so that the messages make sense as there are no bit shifts

during the reading or writing of messages. This field is defined by an alternate 10-bit

train (0101010101) monitored by the master control unit.

The identifier field (8 bits) indicates the number of data fields that form a

response and implies the identification of the message (six bits). This field also

serves to verify the absence of errors in the transmission of messages by using the

last two bits.

Image 1 Message Header and Response

But also, there are several different frame types in Local Interconnect Network

(LIN), each contributing specific functionality to the data link layer. For this practice,

we’re explaining the diagnostic frames.

 The diagnostic frames are used in the Transport Layer Specification section

of the LIN v2.2A Specification. Their primary function is in the area implementing

diagnostics and configuration functions.

 Designated Identifiers

o 0x3C (60) Master Request Frame

o 0x3D (61) Slave Response Frame

For this practice we create a schedule to get order in the message

transmission, for this, we did not need the priority ID to get in order the messages,

in this case, by just giving a schedule slot in which we order the messages

transmission and response was enough.

Image 2 LIN Schedule.

Process

First of all the teacher during the class shared a file which we would use to carry out

our practice, the first thing we should do was open the LDF Explorer. In this section

we had to open the LDF of Laboratory 09 as shown below.

 Image 3 LDF Explorer.

What was done later was to create each of the messages that were indicated

in practice since the objective of this is to carry out the communication of the nodes.

As you can see, the mMasterTX and mSlaveTX messages with the specified IDs

were generated. In addition, the sSine, STriang, SSqrt and SSlave1_error signals

were added.

Image 4 Schedule Tables.

Since each of the messages with each of the specified signals was had, the

one in charge of handling each of the ECUs is the LIN_Master and the Subscriber

without any doubt was Slave 1.

 Image 5 ECU´s and Subscriber´s.

Later the LDF code was made to control each of the emitted signals. The code

was as follows.

LIN_description_file;
LIN_protocol_version = "2.1";
LIN_language_version = "2.1";
LIN_speed = 19.2 kbps;

Nodes {
Master: LIN_Master, 1 ms, 0 ms ;
Slaves: Slave1 ;
}

Signals {
sSine: 8, 0, LIN_Master, Slave1 ;
sTriang: 8, 0, LIN_Master, Slave1 ;
sSqrt: 8, 0, Slave1, LIN_Master ;
sSlave1_error: 1, 0, Slave1, LIN_Master ;
sTemp: 8, 0, LIN_Master, Slave1 ;
}
Diagnostic_signals {
MasterReqB0: 8, 0 ;
MasterReqB1: 8, 0 ;
MasterReqB2: 8, 0 ;
MasterReqB3: 8, 0 ;
MasterReqB4: 8, 0 ;
MasterReqB5: 8, 0 ;
MasterReqB6: 8, 0 ;
MasterReqB7: 8, 0 ;
SlaveRespB0: 8, 0 ;
SlaveRespB1: 8, 0 ;
SlaveRespB2: 8, 0 ;
SlaveRespB3: 8, 0 ;
 SlaveRespB4: 8, 0 ;
SlaveRespB5: 8, 0 ;
SlaveRespB6: 8, 0 ;
SlaveRespB7: 8, 0 ;
}
Frames {
mMasterTX: 16, LIN_Master, 2 {
sSine, 0 ;
sTriang, 8 ;
}
mSlaveTX: 18, Slave1, 2 {
sSqrt, 0 ;
sSlave1_error, 8 ;
}
PostLab: 0, LIN_Master, 8 {
sTemp, 0 ;
}
}
Diagnostic_frames {
MasterReq: 0x3c {
MasterReqB0, 0 ;
MasterReqB1, 8 ;
MasterReqB2, 16 ;
MasterReqB3, 24 ;
MasterReqB4, 32 ;
MasterReqB5, 40 ;
MasterReqB6, 48 ;
MasterReqB7, 56 ;
}
SlaveResp: 0x3d {
SlaveRespB0, 0 ;
SlaveRespB1, 8 ;
SlaveRespB2, 16 ;
SlaveRespB3, 24 ;
SlaveRespB4, 32 ;
SlaveRespB5, 40 ;
SlaveRespB6, 48 ;
SlaveRespB7, 56 ;
}
}
Node_attributes {
Slave1{
LIN_protocol = "2.1" ;
configured_NAD = 0xFF ;
initial_NAD = 0xFF ;
product_id = 0x0, 0x0, 255 ;
P2_min = 50 ms ;
ST_min = 0 ms ;
N_As_timeout = 1000 ms ;
 N_Cr_timeout = 1000 ms ;
configurable_frames {
mMasterTX ;
mSlaveTX ;
PostLab ;
}
}
}
Schedule_tables {
Lab09_Schedule {
mMasterTX delay 5 ms ;
mSlaveTX delay 5 ms ;
mSlaveTX delay 5 ms ;
mMasterTX delay 5 ms ;
mSlaveTX delay 5 ms ;
mSlaveTX delay 5 ms ;
mSlaveTX delay 5 ms ;
}
}

Post-laboratory

For the post lab, what was done was to create a new message issued by the teacher

with a signal named sTemp, therefore the same procedure as we had done

previously was performed.

As we can see now we have the signal named sTemp with an initial value of

0 and with a bit length of 8.

Image 6 Signal Properties.

 Since each of the messages with each of the specified signals was had, the

one in charge of handling each of the ECUs is the LIN_Master and the Subscriber

without any doubt was Slave 1.

Image 7 Post-laboratory ECU´s and Subscriber´s.

It should be noted that the LDF code was modified a bit since the new sTemp

signal was added.

Results expected
The LFD Explorer tool was used to design a LIN network that can perform

communication between two nodes which are the LIN Master and Slave 1. In

addition, the mMasterTX and mSlaveTX messages were generated with the IDs

specified above.

The sSine, STriang, SSqrt and SSlave1_error signals will be generated and

added to the signals of unconditional frames located in the mMasterTX.

Results obtained

After putting all the signals with the messages and the messages with the nodes, we

got our principle window like the next image.

 Image 8 Unconditional Frames and Messages.

After getting all together, we order the layer to get our bits in order to get our

must significant signal at the end of our layer, in the case of all the messages the

temperature were our most important signal because the ID (Identification) is 0 and

therefore it is the most significant bit.

It is important to emphasize that the transmission rate at which one works for

being a LIN model is 19,200 kbps. The Diagnostic Frames are Master Request with

the ID 60 and Slave Request with the ID 61.

Image 9 Diagnostic Frames and Properties.

Theoretical practical comparison

As we could see during the development of the practice, the whole procedure that

was carried out from the creation of each of the nodes, until the modifications of the

“layout” were in the computer, each of these steps was described by the teacher

during the class and the work of us was to carry out the post-laboratory which

consisted of enclosing a “sTemp” message and adding it to our messages for each

of the nodes with the specifications that were previously seen.

There were some problems at the time of modifying our file made in class

since we added entries where exits went and vice versa; but we were able to solve

these inconveniences and the development of the practice was carried out in the

best way. Each of the data obtained both in practice and in the post-laboratory were

analyzed to have a better performance in the evaluation of this.

Conclusion

The versatility of CANoe software helps us to better understand people who are just

beginning to learn about the use of automotive networks and to interact with a car

system database.

In this practice, the knowledge acquired by the students in the CANoe

program was tested to verify what was learned during the classes for the

development of the practices and to reinforce the theoretical knowledge of the

subject.
 The data collected by the CANoe software in the simulations are very

important since with them we can perform the refinement of these; with this, a more

effective communication network with better results can be obtained. Also, with the

different tools that the software has, we can obtain the data of the signals sent by

the bus and thus be able to analyze if everything goes according to the schedule.

Bibliography

1. Xiao, Z., & Li, Y. (2011, July). Hardware design of automobile door with local
interconnect network bus. In 2011 International Conference on Control,
Automation and Systems Engineering (CASE) (pp. 1-4). IEEE.
2. Kastenholz, F., Westberg, T., & Willis, S. R. (2005). U.S. Patent No.
6,980,543. Washington, DC: U.S. Patent and Trademark Office.
3. Ruff, M. (2003, October). Evolution of local interconnect network (LIN)
solutions. In 2003 IEEE 58th Vehicular Technology Conference. VTC 2003-
Fall (IEEE Cat. No. 03CH37484) (Vol. 5, pp. 3382-3389). IEEE.
4. Artal, J. S., Caraballo, J., & Dufo, R. Protocolo CAN/LIN-Bus. Implementación
de una red de comunicación serie de bajo coste.