With thousands of data parameters flowing continuously along one or more CAN Buses in any particular vehicle, there is no doubt that finding out what these parameters mean can be very benificial, but, in having the data, you can also use it to simulate what is there.
So why would you want to simulate what is ALREADY there? One, because you want to get rid of what is there and add something of your own. Removing the engine and engine controller? No problem just simulate it, the other modules probably wont care. Removing the driver or passenger seat, no problem just simulate it, the other modules probably wont care.
Or two, you want to enhance the functionality of existing controllers. Want the doors to auto-lock at 2mph not 5mph? No problem simulate the lock message, the doors won’t mind. Want to have the vehicle chime all the time while the seat belts aren’t buckled, no problem simulate the chime.
So how does simulation work? Typically, you will need to look at the message(s) that you want to simulate. What is there Arbitration ID? What is there data length? Is the data static or dynamic? Is it sent periodically, on event, or both? If you send the message and do not remove the original controller that is sending the message are the desired results nullified by the original controller (i.e. if you are sending head lights ON and the original controller is sending head lights OFF, do the headlight turn ON, OFF or flicker?) ?
Once you’ve answered these questions, then you are ready to begin. So what was the Arbitration ID? Let’s say it was 0x555. Ok now what’s the data length? 8 bytes with static data, sent periodically at 100ms update rate.
Let’s assume this message is a command that moves the driver mirror up when we change the first byte from 0x00 to 0x01. So the message on the Bus looks something like this: 0x555 00 00 00 00 00 00 00 00. But if we send our simulated message of 0x555 01 00 00 00 00 00 00 00 the mirror will move up just a smidge and if we send it at 100ms it will continue to move up until we stop sending or we change the first data byte from 0x01 back to 0x00. However we may notice that the upward movement of the mirror is not as smooth as when I press the up button of the mirror control switch. This is because you are simulating a message that is already present on the CAN Bus. This means that the receiving controller is receiving your message 0x01 and the original controller’s message 0x00 and interpreting an Up command when your message arrives and a Stop command when the original controller’s message arrives. Depending on how well or bad the software for the mirror control module is written, this may cause havoc on the system you plan to implement, and will most definitely be the source of many CAN Bus Error frames (don’t worry there not too bad, in general it is almost impossible to cause any issue when simulating an existing CAN Arbitration ID).
So, in this instants, if we want to make the control as smooth as the original switch, we must stop the existing controller from sending the message. There are a couple of ways to do this, the first is obvious, disconnect or power-down the original controller. Remove a fuse, disconnect the CAN Bus or power from the controller. Now of course this will most definitely have other symptoms, but if your application can tolerate this, then its the easiest and simplest solution.
Next to physically disconnecting the module is using diagnostic messaging to ask the module the stop sending. Often called Disable Normal Communications. If supported, this service will make the module stop sending its data. The problem is that the message format and rules are typically quite different from vehicle manufacture to manufacture, so unless you know what this message is, it is difficult to make this work. Plus this method suffers similar draw-backs as the power-down method mentioned above.
Last, you can gateway the message. Gatewaying the message is done by disconnecting the sending OR receiving module (typically easier when it is the receiver). Once disconnected, you can gateway all of the message to the receiving module EXECPT the one that you want to simulate. This allows you to have complete control over the data in that message while maintaining the messages and data from other modules. As you can imagine this solution requires the most work because you must have a device that is fast, support at least two identical CAN Bus channels, and is quickly programmable. But if you can get these three things together, you will can simulate nearly any message with nearly zero issues.
Well this has been some simulating conversation…
