DIN Rail-based Control and Instrumentation Bus

In contrast to the Automated Test Equipment Mainframe (which, as its name suggests, was designed to allow multiple modules to be brought together to create a larger, interactive and programmable piece of test equipment), this bus more about building control systems out of standalone controllers and I/O modules in a master-slave configuration. The resulting control systems would typically be run autonomously, and be divided along (DIN) rail boundaries.

While this system still use a shared TTL-UART bus to allow controller modules to be queried and reprogrammed via a single USB-to-TTL serial interface, the bulk of the 'peripherals' — be they sensors, drivers or smaller, bare-bones microcontrollers — would likely be connected to the controller via an SPI bus to query, program and synchronise the various modules. To keep costs down, all modules, controllers and I/O boards alike, should be designed to support daisy-chaining.

• Support a shared inter-module control bus
• Do so in a way which neither ties up all of the available intra-module SPI or I2C buses, nor makes the system vulnerable to inter-module conflicts or I2C device address contention
• Ideally do so in a way that is compatible with ATmega 328P-based microcontroller boards (e.g. the Arduino Nano / Mini Pro)
• Shared power and reset lines, and a backplane that automatically sets the unit IDs based upon slot position
• A software-level command interface that allows individual modules to be addressed, but which also allows for 'group' or chassis-wide events such as triggers, etc.
• Ideally uses a command interface / syntax which resembles existing / industry standards