I'm having issues designing an architecture for communication in a vehicle. Currently a PC is connected through a switch to a series of ECUS, each one with a TCP2CAN converter. The PC has to be started prior to the ignition of the vehicle, which is the main issue, in order to keep the watchdog of the master ECU alive.

I'm searching for solutions to do this in an automated way, meaning vehicle's ignition, turns on a device (call it PLC or Microcontroller) which is able to handle this TCP messages (RAW) and send them to their correct destinations This implies timing limitations in the system, to keep watchdogs alive.

I've found multiple PLCs with Modbus TCP IP protocol, but I'm unsure whether this is equivalent to TCP/IP. I've also search in other questions and answers, but most of the TCP/IP questions refer to a stack in a microcontroller. I'm open to other solutions (not necessarily a PLC), as long as I am able to work as a gateway to interact with TCP/IP messages (read them and modify them accordingly).

  • \$\begingroup\$ Most PLC that offer TCP/IP have the ability to write to raw sockets, not using any other higher level protocol. However, product recommendation are considered off-topic. \$\endgroup\$ – Jeroen3 Sep 12 '18 at 14:05
  • \$\begingroup\$ Your question is missing a critical component: what are the "multiple devices". Your question is close to being closed as off-topic. You need to edit quickly to keep it open. It needs to be a design question. \$\endgroup\$ – Transistor Sep 12 '18 at 15:36
  • \$\begingroup\$ @Transistor I'm communicating with ECUs in a vehicle, which make use of an TCP2CAN conversion. The packets are managed RAW through TCP, with the data protocol specified by the CAN unit. This implies timing limitations in the system, to keep watchdogs alive. \$\endgroup\$ – magni Sep 12 '18 at 15:42
  • 1
    \$\begingroup\$ Put that information into your question then and edit it to ask what protocols the PLC would need to support to access those devices. Remove the "I'm searching for a PLC ..." as this is the problem 'shopping' part of your question. \$\endgroup\$ – Transistor Sep 12 '18 at 15:44
  • \$\begingroup\$ Quite complicated thing, even more if you need a robust system as industrial PLC, usually they are very limited. However there are also opensource industrial gateways. If time and money is not a problemm, you might look this: 14core.com/… \$\endgroup\$ – Marko Buršič Sep 12 '18 at 16:14

MODBUS TCP, TCP, and IP are all different layers that stack up to form a complete communications channel.

IP is the network layer, and handles how packets of data get moved from node to node across a network (or between networks). In the OSI model, this is Layer 3.

TCP is a transport layer (Layer 4) that operates 'on top of' the IP layer, and provides connection-based logical link between devices on the network.

MODBUS TCP is a protocol that is transported via TCP, and is essentially a networked version of the pre-existing MODBUS protocol that's commonly used over serial links in industry.

So in order to use MODBUS TCP, you need to have the underlying layers in place first. You need two devices that support TCP connections, and TCP needs IP, and IP in turn needs a data link layer and physical medium to move across (usually Ethernet, but could also be fiber or radio).

In addition to MODBUS, there are other transport protocols that work over TCP--you are reading this text thanks to HTTP. Likewise, you can use IP without TCP, for instance there are a number of protocols that use UDP, which is connectionless and so simpler to implement, and facilitates multicasting.

Before you can determine the best solution for your application, you'll need to better define your needs. MODBUS is based on reading and writing to logical "registers" and "coils" (essentially bits). If that functionality maps well to your application, then off-the-shelf devices that implement MODBUS TCP could be a good fit. If you need more flexibility in the structure of the data or the nature of your transactions, then you'll need to find or create a different protocol.

If you want an embedded device, there are plenty of microcontroller platforms and dev boards that provide Ethernet connectivity with good support for bringing up a TCP stack in software. But a good place to start may be on a PC, where you can write more sophisticated software more quickly to model your data flow and prototype some potential solutions.

  • \$\begingroup\$ The thing is I have some limitations regarding timing constraints, which a PC might not fulfill. I need a system able to handle and manipulate Raw TCP messages, with a short startup-time. Currently a PC (always on) does the job just fine, but I need a embedded system able to do the work, which starts at the same time as the other communication units. I know this is very specific but otherwise watchdogs in the communication chain will not be fed in time. \$\endgroup\$ – magni Sep 12 '18 at 15:38

You have a watchdog which resets the engine control unit if a PC fails to send an internet packet in time. If this happens in an actual vehicle, your choice for the source of IP packets is limited by safety norms. You will never be able to certify your architecture if you use a microcontroller or a PLC with a generic Ethernet interface. You'll need an Ethernet controller with guaranteed reliability and QoS, otherwise you won't be able to demonstrate that your system prevents delaying or accidentally corrupting IP packets, which in your case would result in a sudden engine stall.

I'm not trying to suggest a product in particular, but check out this product overview article from Synopsis to see what I'm talking about.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.