BasicPI

Part 1 of this article summarized scope of work because software for an ECU basically have two core bulks – one is the core and main controller, while the second is the add-one modules and specialized IO. This second part is basically endless as we will be adding more features and more hardware, so in this summary I want to focus on the main controllers. The block diagram below outline the main components.

RTOS that I use can be FreeRTOS, ThreadX or whatever, but I always add a barebone, linear scheduler as well because that enables FW to scale better. Most of the times I just run barebone, but I can always add a thread shifter if needed. RTOS must provide a set of critical functions that all SW is allowed to use – two of them are functions like millis() and microes() to measure elapsed time. The key functionality is however an easy path to set up tasks and decide how they execute for the system to work.

HAL (Hardware Abstraction Layer) is whatever drivers you get from a vendor and that interface to hardware. The challenge with this layer is that it is not a proper abstraction layer as different vendors will have different drivers and diffenert aproack to do the same thing.

AL (Abstraction Layer) is my own C++ layer to access hardware or software that I want to re-use in an uniform way to protect code. Using HAL drivers comes at a price – overhead and specialized hardware interface + I sometimes need to deal with workarounds or simply want a simpler interface. Also I sometimes need low level drivers that are fast and C++ is well suited to have a nice interface to a tight assembly function should I need to. Ethernet as an example can be a hardware or software interface and I need an uniform way that hide this complexity. The AL is common in all my systems and RTOS is part of the AL library.

Primary CAN is the CAN port combined with the 8-30V PSU connector. I initially had a separate PSU connector, but decided that since all main boards have CAN-FD I can as well add one here using the NMEA2000 layout. This also gives me easy access to cable infrastructure. The primary CAN can be used like any other CAN port, but it is also linked to CLI giving access to all configuration.

USB is used as a serial driver to enable a PC to connect, even power a motherboard from USB and configure it using USB. We might add more sofisticated methods later, but as a start you will need to connect to the USB for (1) configuring the system and (2) downloading new firmware.

CLI (Command Line Interface) is a text based command utility that allow you to interact directly with the system, configure components, modules and load new firmware.

Bootloader is a small FW package that is executed at start-up to check if a new FW is needed. For the main controller we download FW as an image on the disk and as we restart that FW is loaded. For the modules this operation is controlled by the mainboard, so we download to mainboard that then download to the modules. The bootloader cannot be broken, but a FW upload might fail in which case we restart the download procedure. We also have the option to rollback to a previous download as we can store multiple images on Disc.

Power Management. As we have multiple IO modules drawing Power we need to monitor their power usage and switch them on/off as needed. All motherboards can switch on/off any sub-module as needed. This includes logic to blacklist non-working modules – in which case we raise a sub-system down alarm.

Dictionary is our central database partly in RAM and partly on disk. This is a list of variables, tables, modules etc – everything we use in the system. The Dictionary  list the content primarely being an index, but the actual data can be located in user modules or copied in the Dictionary + FW images will always be on disk. One module interface to another through the dictionary which makes it easy to build a distributed system as modules can be located on different nodes if required.

Disk is an extension of dictionary where selected variables are stored on SPI Flash when changed. FW images are only stored on disk. At start-up the system will read all parameters to initialize the system. After that we save parameters then changed.

Event Distribution, As variables in the dictionary change we can signal receive tasks to pick up the changes – this can be done per variable or for a set of variables. If we are on the same MCU this will mean one task change a variable and another one deals with that change within 50yS. If we are on different Nodes we can still interact within 500yS and maybe faster. Also multiple modules can interact with the same module with no extra effort. Signals within tasks are very efficient, but you can also do a check every 10ms scheme or similar. If the receiver of a signal is a communication port then the receiver will pick up data and transfer it on the bus as fast as possible.

Module IO is a generic protocol as the motherboard assumes nothing about a module. In the config we will have a list of what we expect and as we start each module we do an identification. Each module have an unique type number and id, so the motherboard can instantly see if this is what we expected or something else. If it is a new module we need to load it’s part of the dictionary so that modules using this one find data they look for. Process for staring is very fast and easy, while process for connecting new modules will require a bit more communication depending on module.

Obviously it is a lot more details to the functionality than mentioned here, but is should give you a brief idea of how it all plugs together.

I have started the FW on the ECU that will take a while, but I can outline the main design principles I use:

ECU Hardware consist of a a motherboard with a M12-4 Power connector. I use the same format as NMEA2000, but allow for 8V to 30ichV PSU rather than only 12V. I do however add the CAN port so that we can re-use NMEA2000 infrastructure as well as claim NMEA2000 compability. So that gives us CAN as primary interface.

I also add an USB as a serial port because it is convenient to just plug the main board to a PC for direct, first time configuration this way. Through this we can do CLI scripting to configure the node and detect what’s on it.

My current motherboards have PCB layout for one Ethernet, but I am not sure I want to keep that. I have two Ethernet modules that are better as they have separate MCU’s offloading some of the work. So – I think the Ethernet port can be dropped in favor of other features on the motherboard.

Disk is SPI-Flash, SPI-FRAM or SPI-PSRAM. Each motherboard will as a minimum have a SPI-Flash.

The Motherboard is a powerfully MCU acting as a switch between all interfaces. I want to keep this as simple as possible, but it also have capabilities to run automation based on data from multiple modules.

What makes this design special is the add-on modules, because you take a small box and add up to 8 modules to get the IO you want. Each modul vary in IO, but they have the same interface to the motherboard. This is a star design so one module will need to send messages to another module through the motherboard – or more correctly the motherboard is configured to forward seleced messages to the modules – something you can configure.

My modules that are in progress are as follows:

• CAN Module. Fitted with a small MCU and fully galvanic CAN interface using NMEA2000 standard we can make a CAN Hub with 8 ports easely. In fact we can link Nodes and create a CAN Hub that is as large as we want as long as we remember to do bandwidth calculations.
• RS485 my newest board is mostly for Modbus. This old protocol is hard to avoid and is a very handy interface as many 3rd party components will support this.
• Single Ethernet connection so we can hook up standard Ethernet and work.
• Tripple Ethernet connection with a switch in the connection so that we have two external ports and one internal. This is needed for low level Profibus or Ethercat support, but it also allows us to daisy chain Ethernet and avoid a centralized switch.

As for the rest we need some actual IO:

• Analogue IO. I designed a fast, high precision AI board capable of recording 3 channels at 65Kbps with 24 bit resolition. This is primarely designed for vibration sensors, but it is a generic 3 – single lines, or 2 delta lines fully galvanic isolated.
• Digital Out – An 8 port digital out capable of multiple ampers and PWM with load detection and current sensors. This can be used as a Power source or as a 3-phase motor driver, solenoid driver, stepper motor driver or DC motor driver.

I have plans for multiple boards, but the only one I actually need fast is a Power Servo Controller. I have some 150Kg Servo drivers I want to put into usage and they need multiple voltages and proper servo signals – which brings me to one more module:

I will need a PSU capable of delivering some Ampere on multiple voltages from 48V, 24V, 12V, 8V and 5V. I use 24V as base, but IO modules sometimes need a secondary source with different voltage, so the 24V is basically for control systems and remember that we talk 8-30V and not just 24V.

I have one more module coming up  – this is work in progress, but it is a motor controller targeting 12KW motors. It’s actual capacity is 48V-1200V and some 50A, but it will be designed to sustain 12KW and hence be in the smaller and lower side of motor controllers. The interesting part on this is that total size is very small and that it comes with 10 possible Add-On modules.

It has current sensors, but Resolver, Encoder, Hall Sensors and end points + extra sensors you add through an add-on module. On the left side I have space to add a break-resistor or a sinus filter – the later is needed for induction motors as this can drive all type of 3-phase motore. The design parameters are 600V/20A, but the board is capable of 2 x that.

This is designed for a standard aluminium box and MOSFET’s are underneath directly connected to heatsinks, but we talk about something like 15W in loss on 12KW. I can mount extra heat sinks if needed, but I am not sure I need to on this one.

In short – this is a motor controller where you add the PLC as modules inside the controller to reduce need of extra space and components. My calculations indicate a cost base on ca 300.- USD even for low volumes, and these controllers are usually priced between 1000 to 4000.- USD depending on content.

As this also is an ECU motherboard it will use the same FW as the ECU’s but add current sensors and motor control – I hope to mount the first prototype during x-mas. I need to finish the design and order PCB’s, because I will probably need 3 rounds on this before I am happy.

The content of this HW summary will change as we move forward, but it serve as a reminder of what we need to solve in SW – that will be described in part 2.