3.2. Operating System Configuration

As previously stated, one design paradigm is that all application code runs within the context of an operating system. In detail, this means that various tasks with different priorities are used to ensure the necessary real-time behavior of the BMS as shown in Fig. 3.4.

Tasks & Priorities

Fig. 3.4 foxBMS 2 Tasks & Priorities

Two different task implementations are used:

  • Cyclic executed task in non-blocking mode with a fixed period (1ms, 10ms, 100ms)

  • Consecutive running task in blocking-mode

Four scheduled tasks with a period of 1ms, 10ms, and 100ms, are configured to execute the various deterministic finite-state machines that describe the behavior of the BMS as shown in Fig. 3.5.

Task Model - Cyclic Tasks

Fig. 3.5 foxBMS 2 Task Model - Cyclic Tasks

Time-sensitive software modules (e.g., diagnostics, measurement, CAN reception) are called within the 1ms Task, whereas less time critical modules (e.g., CAN transmission, interlock, BMS) are implemented inside the 10ms Task. Software modules that are temporally uncritical (e.g., state estimation, balancing) are handled by the 100ms Task. The additional 100ms Algorithm Task can be used for advanced user specific algorithms (e.g., moving averages, computation intensive state estimation algorithms).

Additional functionality is provided in through continuous running tasks that are implemented in blocking-mode. This means, that the detailed function implementation in these tasks defines the actual timing behavior (e.g., running time, blocking duration). The continuous running tasks are shown in Fig. 3.6.

Task Model - Continuous Running Tasks

Fig. 3.6 foxBMS 2 Task Model - Continuous Running Tasks

The Engine Task is used to implement a data-exchange layer between the different tasks and processes. This data-exchange layer runs with the highest priority of all tasks and is interfaced using queues to either send or to receive data entries. These FreeRTOS queues are formally verified for memory safety, thread safety and functional correctness. Depending on the selected AFE, the respective driver is either implemented as non-blocking variant (executed in the 1ms Task) or blocking and then running in the AFE Task. All drivers for hardware peripherals with an I2C Module interface on the foxBMS BMS-Master are called within the I2C Task. The UART Task is used to handle the UART software flowcontrol. The Idle Task is executed if all other tasks are currently blocked or are waiting to be executed again.

In general all TCP/IP related tasks have a lower priority than the tasks that are relevant for the core functionalities of the BMS. The TCP/IP related tasks are the EMAC Task, the IP-Task and the IP Application Tasks which can be more than one. These Tasks are displayed in figure Fig. 3.7.

Task Model - Priority diagram

Fig. 3.7 foxBMS 2 Task Model - Priority Diagram

In the EMAC Task the reception of the EMAC is handled. In line with the FreeRTOS recommendations the receiving task (EMAC Task) has the highest priority from the TCP/IP related tasks. It is directly responding to hardware interrupts. The IP-Task runs with lower priority as it handles more complex operations. This allows the Receive Task to do its job without interruption. The IP Application Tasks use the TCP/IP API to send and receive data have the lowest priority. This prevents them from starving the time-sensitive network handling done by the IP-Task.

The TCP/IP related tasks and UART Task are disabled by default. To enable them the configuration needs to be adapted as in rtos or respectively in debug.