# Cyborgan OS: A Lightweight Real-Time Operating System for Artificial Organ

Authors: Pan Lv; Hong Li; Jinsong Qiu; Yiqi Li; Gang Pan
Journal: Security and Communication Networks
 (2020)

---

## Abstract

The software of artificial organ is more and more complex, but it lacks real-time operating system to manage and schedule its resources. In this paper, we propose a lightweight real-time operating system (RTOS) Cyborgan OS based on the SmartOSEK OS. Cyborgan OS optimizes and improves it from the code size, context switch, low power consumption, and partial dynamic update, making it suitable for the artificial organ control system. Finally, we use the heart blood pump model to analyze the task allocation and execution sequence as well as the code size of the whole program. In this application, the maximum space occupied by the code is only 15 kB, which is suitable for most microcontrollers.


---

## Body

## 1. Introduction

Cyborg is a biological creature whose functioning has been enhanced through integration of mechanical, electrical, computational, or otherwise artificial components [1]. Among them, the artificial organ and cyborg insect are typical representatives [2, 3]. From a perspective provided by Zheng et al., the human will be enhanced by artificial electromechanical components and become new cyborg intelligent systems [4, 5].In the field of artificial organs, a lot of research work is focused on organ materials, mechanical structure design, application systems, and so on [6, 7]. Kosaka et al. have proposed a remote artificial heart monitoring system based on Internet and noninvasive sensors, which can manage the physiological state of patients and the working state of artificial heart in real time and effectively [8]. The authors in [9] propose a microcontroller pacemaker for bradycardia pacing, along with a PC-based programmer. Its algorithm is implemented in Arduino microcontrollers, which is programmed using PC and MATLAB. Markovic et al. design a blood pump for a wearable artificial kidney device. Its control system for the operation of the blood pump is composed of a central computer, power cards, and position measurement cards [10]. The power card contains a microcontroller STM32F103, which controls the power switch of the blood pump. Despite all those accomplishments, according to our limited knowledge, there is no special operating system for artificial organs. As the artificial organs are becoming more powerful, especially the application of smartphones in artificial organs, the complexity of artificial organ is greatly increased [11]. It is necessary to resort to unified management and scheduling of hardware and software resources of artificial organs. Therefore, it is advisable to adopt an embedded RTOS as the basic software platform of artificial organs. Limited by the physical conditions of human body, microcontrollers used in artificial organs generally have limited memory and very small battery capacity. This application scenario requires the embedded RTOS to be lightweight and of low power consumption at system level to extend battery life.This paper designs and implements a lightweight real-time OS for artificial organs and names it Cyborgan OS. The main contributions of this paper are as follows:(1)
Lightweight kernel: we implement a 10 kB level kernel based on priority scheduling, which is suitable for most Microcontroller Units (MCU)(2)
Low power design: by optimizing the system operation and taking the task wake-up alignment method, we reduce the system power consumption(3)
Partial dynamic software update: to make the artificial organ have the ability of function upgrade, we have realized partial dynamic software update, which makes the software upgrade without having to halt the operating systemThe rest of this paper is organized as follows. Section2 introduces the related work. Section 3 outlines the system overview of the Cyborgan OS. Section 4 describes the basic functionality of the Cyborgan OS kernel. Section 5 presents the power management service and the partial dynamic software update service employed in implementing the Cyborgan OS. Section 6 provides a concrete application example to evaluate Cyborgan OS. Finally, the conclusions are drawn in Section 7.


## 2. Related Work

In the field of Internet of Things (IoT), operating system, communication, security, and cloud task scheduling are the key technologies [12–15]. Artificial organs are a typical application scenario of operating system for low-end IoT devices since artificial organs are generally built around a microcontroller with very constrained memory and small battery capacity. Hence, the same challenges are posed for OS designers for artificial organs when it comes to handling the highly limited hardware resources.A generic OS for low-end IoT devices should have a small memory footprint, support for heterogeneous hardware, network connectivity, energy efficiency real-time capability, and security [16]. TinyOS is one of the earliest application-specific operating systems that directly deals with the limitations of sensor devices. It has a lightweight event scheduler where all program executions are performed in tasks that run to completion [17]. In contrast to TinyOS, Contiki is a lightweight operating system that supports dynamic loading and replacement of individual programs and services during run-time and without relinking [18]. Contiki has an event-driven kernel. FreeRTOS is a popular RTOS and has been ported to many MCUs [19]. Multithreading is supported by its preemptive microkernel and a tickless mode is provided for low power applications. The application firmware is written using FreeRTOS, and hence the device functionality is guaranteed and is designed to resist failures due to software malfunctions [20]. RIOT is an open-source microkernel-based RTOS that aims for a developer-friendly programming model and API [21]. Developed with the particular requirements of low-power wireless IoT devices in mind, RIOT uses an architecture inherited from FireKernel and provides support for multithreading with standard API [22].Compared with the previous operating system, the SmartOSEK OS that our design is based on is an embedded RTOS for automotive electronics. It guarantees real-time and reliability through full preemptive task scheduling and static memory allocation [23, 24]. The kernel of SmartOSEK OS is configurable and tailorable, so its code size can be small.In terms of embedded low-power technology, Dynamic Voltage and Frequency Scaling (DVFS) is an effective energy-saving technology, which is widely used in embedded systems. Classic DVS algorithms include the PAST algorithm proposed by Weiser, the AQRS algorithm proposed by Yao et al. [25, 26]. FreeRTOS applies a tickless idle technique to achieve more power saving during the processor idle periods [27].For the moment, most dynamic software updates designed for embedded systems are achieved via bootloader, which is a part of the microcontroller [28–30]. But the software update method via bootloader has a drawback that the update involves the whole system and will halt the entire system when the update is underway. When it comes to artificial organs, as they are already implanted in the human body, halting the control system can be dangerous and is catastrophic. Also it is mentioned in [31] that the communication rate of artificial organs is relatively low, and the partial dynamic software update method can reduce the amount of code to be updated and reduce the update time consumption. In this study, we propose a method of partial dynamic software updating, which can update the program without stopping the system.


## 3. System Overview

The Cyborgan OS consists of kernel, service, and driver as shown in Figure1. In the OS kernel, task, interrupt, and alarm are the minimum function subsets to realize the operating system functions. The other four modules can be tailored according to the needs. In this way, the memory footprint of the OS kernel can be reduced as much as possible, so as to adapt to more types of microcontrollers.Figure 1
Architecture of Cyborgan OS.The service layer abstracts common functions into services and provides them for system or application calls. At present, we have implemented two services: power management service and partial software update service. The driver layer realizes the basic hardware drivers such as microcontroller drivers, communication drivers, and I/O drivers. Given that drivers are already very common technologies, this paper will not introduce them in detail. As mentioned above, the Cyborgan OS is designed to provide a lightweight operating system kernel with low power consumption to provide system level support for the complex functionality of artificial organs. Therefore, its design should follow several principles:(1)
Real-time: In common scenarios of real-time control systems such as blood pump of artificial heart, it is often required that the microcontroller gives a response within a predefined time interval. Hence, the Cyborgan OS should support real-time task scheduling.(2)
Tailorability: The Cyborgan OS needs good tailorability, because when constructing different applications, irrelevant modules can be deleted considering the limited memory resources of the microcontroller chip.(3)
Low power design: Artificial organs installed inside human bodies often cannot obtain stable and continuous power supply. Hence, the operating system should have low power consumption and can switch dynamically between operating modes in accordance with the task status.(4)
Partial dynamic software update: During the software update, the normal functioning of artificial organs cannot be halted, and the update should be done as quickly as possible. So partial dynamic software update is applied to upgrade the functions of artificial organs.


## 4. Cyborgan OS Kernel

The kernel of Cyborgan OS initially evolved from the SmartOSEK OS [24]. It provides basic functions such as task management, interrupt management, alarm mechanism, resource management, event mechanism, messages handling mechanism, and error handling mechanism. The last four functions can be tailored dynamically according to the requirements of artificial organ applications to reduce the kernel size. All other functional components, such as power management and partial dynamic software update, are kept separate from the kernel and described in the next section.


### 4.1. Task Management

In common scenarios of real-time control systems such as the blood pump of artificial heart, the control software of artificial organs can be subdivided into functions implemented in the form of tasks. It is often required that the microcontroller give a response within a predefined time interval. Hence, the Cyborgan OS supports fully preemptive scheduling policies. For example, in the application of artificial heart, blood pump must run periodically, its control task should have the highest priority, and it can preempt low priority tasks such as external communication.In order to save the task switching time of Cyborgan OS, we optimize the task switching according to the method in paper [32]. As shown in Figure 2, the basic idea is to divide the ready state into intermediate state and initial state. According to different states, different task context switching methods are used to improve the task switching speed. When the current running task is terminated into suspended state, it is not necessary to save the context because the task in the suspended state has finished. The task in initial state that is ready to run is a completely new task, so there is no context to recover from. In other words, context switching is needed only when the task enters or leaves the intermediate state.Figure 2
The improved basic task model [32].In the application of artificial organs, the execution of tasks is often serialized, and preemption of normal tasks rarely occurs; that is, tasks rarely enter the intermediate state. Therefore, this context switching method can improve the speed of task switching.


### 4.2. Messages Handling Mechanism

The Cyborgan OS uses OSEK COM mechanism to realize message handling. OSEK COM supports m:n-communication [33]. It supports two message types: internal message and external message. The internal message refers to the message transmission between tasks in MCU, which is sent and received using shared memory. The external message is used between MCU through an external physical bus such as SPI.As shown in Figure3, when sending an external message, OSEK COM packs the message in protocol data unit (PDU) and then sends it through the transmission layer. Receiving messages is a reverse process. In this way, the OS can shield the difference of communication hardware and achieve good portability.Figure 3
Structure of message handling mechanism.


### 4.3. Alarm Mechanism

Based on counters, the Cyborgan OS offers alarm mechanisms to handle periodic tasks such as sensor acquisition. A counter tracks the number of ticks and at each tick, the alarm value gets incremented by one. When the alarm value equals the predefined counter value, the OS will activate a task, set an event, or call an alarm callback routine, as shown in Figure4. More than one alarm can be attached to the same counter. In addition, the OS provides services to cancel alarms and to get the current state of an alarm.Figure 4
Structure of alarm mechanism.In the application of artificial organs, there are often periodic tasks such as sensor acquisition and actuator control. In this case, the alarm mechanism can be used to activate the corresponding tasks regularly.


### 4.4. Interrupt Management

The OS encapsulates the interrupt handling mechanism, and the ISR is subdivided into two categories:(1)
ISR category 1: The ISR category 1 does not call any system service. Once the ISR is finished, the systems return to the instruction where the interrupt has occurred. This ISR category does not affect task management.(2)
ISR category 2: The user routine in the ISR category 2 can call system services. When the ISR is done and a preemptable task is interrupted, rescheduling will take place.In Cyborgan OS, interrupts are handled by hardware and can interrupt tasks. If a task is activated from an interrupt routine, the task will be scheduled at the end of all running or queued interrupt routines.


### 4.5. Resource Management

The resource management module handles the situation when tasks of different priority visit simultaneously the shared resources such as the memory and hardware devices. When multiple tasks access the same resource, because the low priority task occupies the resource first, the high priority task sharing access to the resource has to wait the resource; it then makes other low priority tasks run before these high priority tasks. To avoid priority inversion, the priority ceiling protocol is used in the resource management module.In this protocol, each resource is assigned a priority ceiling, which is a priority higher than or equal to the highest priority of any task, which may lock the resource. When a task locks a resource, its priority will be raised immediately to the priority ceiling of the resource. When the task releases the resource, its priority will be dynamically reset to its default priority. A task can lock several resources and is required to release them in the Last In First Out (LIFO) order.


### 4.6. Event Mechanism

The event mechanism is used for task synchronization and is provided only for extended tasks to help these tasks to switch between the wait state and other states. In the system configuration, each extended task is assigned one or several events and is called the owner of these events. An event can only be removed by its owner, and only its owner will wait for it to occur. The OS provides interfaces to set, remove, or wait for events. If a running extended task requires an event that has not yet occurred, the task will switch into the wait state. If the event that a blocked extended task is waiting for occurs, the task will enter the intermediate state. And if the event that a running extended task is waiting for has already occurred, the task will continue running.


### 4.7. Error Handling Mechanism

Besides handling errors by looking at the returned values, the OS also provides a hook routines mechanism in which users can define how to handle certain errors in hook routines. The priority of error handling function is higher than that of any task so that errors can be handled on time. For example, when a sensor of an artificial organ fails, the application can call hook routines to deal with the fault ahead of all other tasks.


## 4.1. Task Management

In common scenarios of real-time control systems such as the blood pump of artificial heart, the control software of artificial organs can be subdivided into functions implemented in the form of tasks. It is often required that the microcontroller give a response within a predefined time interval. Hence, the Cyborgan OS supports fully preemptive scheduling policies. For example, in the application of artificial heart, blood pump must run periodically, its control task should have the highest priority, and it can preempt low priority tasks such as external communication.In order to save the task switching time of Cyborgan OS, we optimize the task switching according to the method in paper [32]. As shown in Figure 2, the basic idea is to divide the ready state into intermediate state and initial state. According to different states, different task context switching methods are used to improve the task switching speed. When the current running task is terminated into suspended state, it is not necessary to save the context because the task in the suspended state has finished. The task in initial state that is ready to run is a completely new task, so there is no context to recover from. In other words, context switching is needed only when the task enters or leaves the intermediate state.Figure 2
The improved basic task model [32].In the application of artificial organs, the execution of tasks is often serialized, and preemption of normal tasks rarely occurs; that is, tasks rarely enter the intermediate state. Therefore, this context switching method can improve the speed of task switching.


## 4.2. Messages Handling Mechanism

The Cyborgan OS uses OSEK COM mechanism to realize message handling. OSEK COM supports m:n-communication [33]. It supports two message types: internal message and external message. The internal message refers to the message transmission between tasks in MCU, which is sent and received using shared memory. The external message is used between MCU through an external physical bus such as SPI.As shown in Figure3, when sending an external message, OSEK COM packs the message in protocol data unit (PDU) and then sends it through the transmission layer. Receiving messages is a reverse process. In this way, the OS can shield the difference of communication hardware and achieve good portability.Figure 3
Structure of message handling mechanism.


## 4.3. Alarm Mechanism

Based on counters, the Cyborgan OS offers alarm mechanisms to handle periodic tasks such as sensor acquisition. A counter tracks the number of ticks and at each tick, the alarm value gets incremented by one. When the alarm value equals the predefined counter value, the OS will activate a task, set an event, or call an alarm callback routine, as shown in Figure4. More than one alarm can be attached to the same counter. In addition, the OS provides services to cancel alarms and to get the current state of an alarm.Figure 4
Structure of alarm mechanism.In the application of artificial organs, there are often periodic tasks such as sensor acquisition and actuator control. In this case, the alarm mechanism can be used to activate the corresponding tasks regularly.


## 4.4. Interrupt Management

The OS encapsulates the interrupt handling mechanism, and the ISR is subdivided into two categories:(1)
ISR category 1: The ISR category 1 does not call any system service. Once the ISR is finished, the systems return to the instruction where the interrupt has occurred. This ISR category does not affect task management.(2)
ISR category 2: The user routine in the ISR category 2 can call system services. When the ISR is done and a preemptable task is interrupted, rescheduling will take place.In Cyborgan OS, interrupts are handled by hardware and can interrupt tasks. If a task is activated from an interrupt routine, the task will be scheduled at the end of all running or queued interrupt routines.


## 4.5. Resource Management

The resource management module handles the situation when tasks of different priority visit simultaneously the shared resources such as the memory and hardware devices. When multiple tasks access the same resource, because the low priority task occupies the resource first, the high priority task sharing access to the resource has to wait the resource; it then makes other low priority tasks run before these high priority tasks. To avoid priority inversion, the priority ceiling protocol is used in the resource management module.In this protocol, each resource is assigned a priority ceiling, which is a priority higher than or equal to the highest priority of any task, which may lock the resource. When a task locks a resource, its priority will be raised immediately to the priority ceiling of the resource. When the task releases the resource, its priority will be dynamically reset to its default priority. A task can lock several resources and is required to release them in the Last In First Out (LIFO) order.


## 4.6. Event Mechanism

The event mechanism is used for task synchronization and is provided only for extended tasks to help these tasks to switch between the wait state and other states. In the system configuration, each extended task is assigned one or several events and is called the owner of these events. An event can only be removed by its owner, and only its owner will wait for it to occur. The OS provides interfaces to set, remove, or wait for events. If a running extended task requires an event that has not yet occurred, the task will switch into the wait state. If the event that a blocked extended task is waiting for occurs, the task will enter the intermediate state. And if the event that a running extended task is waiting for has already occurred, the task will continue running.


## 4.7. Error Handling Mechanism

Besides handling errors by looking at the returned values, the OS also provides a hook routines mechanism in which users can define how to handle certain errors in hook routines. The priority of error handling function is higher than that of any task so that errors can be handled on time. For example, when a sensor of an artificial organ fails, the application can call hook routines to deal with the fault ahead of all other tasks.


## 5. Cyborgan OS Service

In order to better meet the needs of artificial organs for low power consumption and program update, we extend the two services of power management and partial dynamic software update based on the operating system kernel. These services can be started or shut down by the application.


### 5.1. Power Management Service

Based on the low power modes of the microcontroller, Cyborgan OS implements a power management service that enables the operating system to switch between run mode, sleep mode, and stop mode and takes the task wake-up alignment to further alleviate the impact of task switch on system power consumption [34].


#### 5.1.1. System Operation Optimization

In an embedded RTOS, a task is generally activated by event-based triggers or time-based triggers. In the event-based triggering, a task is activated when corresponding event such as an interrupt takes place. After the task is completed, the operating system performs the idle task and waits for the next event to trigger another task. The time-based triggering makes use of the alarm mechanism to periodically activate certain tasks. When the task is executed, the operating system will again perform the idle task. In the SmartOSEK OS, the idle task will do nothing except incrementing an uint8 variable in an infinite loop, which is a waste of system resources.To avoid this waste, the Cyborgan OS will automatically switch to the sleep mode when the idle task is activated. When it needs to terminate the idle task and to perform other tasks, it will automatically switch to the run mode. Assuming that the idle task occupies 50% of the CPU time and the current in the run mode and in the sleep mode is 4 mA and 0.1 mA, respectively, after taking this mode-switching method, the average current is reduced from 4 mA to 2.05 mA, and the power consumption drops by 48.8%, which are significant advances.


#### 5.1.2. Task Wake-up Alignment

In the implementation of the Cyborgan OS, the system tick is triggered by the alarm interrupt and is triggered every 1 ms in the default setting. When the system enters the sleep mode, even if there is no user interrupts tasks to be handled, the system tick will make the operating system switch from the sleep mode to the run mode every 1 ms. Figure5(a) shows the interference from the system tick with the system operation. In [27] tickless idle technique is implemented in FreeRTOS to solve this problem. As shown in Figure 5(b), the tickless idle implies disabling the tick sourced from the idle task function, in order to ensure that the processor remains in the low power mode for longer periods of time. At the moment of entering the low power mode, the information of when a user task has to continue execution is obtained from the delayed task list and is used for the configuring of the timer to generate interrupt and wake up processor just before the task has to be deblocked.Figure 5
Operating system run/sleep mode switch using three strategies: (a) no optimization, (b) tickless idle technique, and (c) task wake-up alignment.(1)
No optimization will bring unnecessary interruptions caused by the system tick, since the system tick changes the value of the timer by the interrupt. Even if there is no user task, it will leave the sleep mode due to the system tick interrupt. Taking this strategy, the power consumption (Pc) is(1)Pc=t1+t2+t3+tTick×tickCnt×a1+tSleep×a2+tickCnt+3×2×a3.(2)
Applying the tickless idle technique, the system tick is temporarily disabled when the system enters the sleep mode and a general-purpose timer clocked with the system clock is used. So unnecessary system tick interrupts will not be generated in the sleep mode, and the power consumption is(2)Pc=t1+t2+t3×a1+tSleep×a2+3×2×a3.(3)
On the basis of the tickless idle technique, the task wake-up alignment further reduces the number of switches between the run mode and the sleep mode. The power consumption is(3)Pc=t1+t2+t3×a1+tSleep×a2+2×a3.In the scenario of artificial organs, most tasks are periodic, so it suffices to trigger them periodically. For this reason, this paper proposes the task wake-up alignment to optimize the system. The task wake-up alignment implies waking up for execution at the same time those tasks need to be waken up. As shown in Figure5(c), when the period of one task is multiple that of another, we can select a time interval and wake up the tasks periodically. After each wake-up, the waken up tasks are triggered and executed in batch. After completing these tasks, the operating system performs the idle task and enters the sleep mode. Compared with the tickless idle technique, the wake-up alignment can further reduce the number of wake-ups and hence the power consumption.As shown in Figure5, Task1, Task2, and Task3 are needed to be waken up during period T. t1, t2 and t3 represent the execution time of Task1, Task2, and Task3, respectively. tSleep represents the time the system is in sleep mode. tTick represents the execution time of each system tick. tickCnt represents the number of ticks in period T. It is assumed that the current is a1 in the run mode, a2 in the sleep mode, and a3 during the mode switch. The three different strategies are analyzed in detail as follows:From the above analysis, we conclude that the task wake-up alignment can achieve lower power consumption.


### 5.2. Partial Dynamic Software Update Service

The application scenario of artificial organs poses two challenges for designers of software update: (1) how to update the program without affecting the system’s normal functioning? (2) If the update fails, how to do the version rollback of the program? To solve these two questions, this paper proposes a partial dynamic software update service.The key of partial dynamic software update lies in the incremental update and rollback mechanism, which means that every single update targets only one function, burning in the new version of the function to replace the old one. Each function that needs to be updated is placed in a predefined program section, ensuring that the update is performed at the function level.Partial dynamic software update divides the microcontroller’s memory into a fixed code area and updatable code area, as shown in Figure6. The kernel of the operating system resides in the fixed code area since it is not allowed to modify the kernel of the operating system. In the early stage of designing the application software for the artificial organs, it is necessary to estimate which functions may need to update afterward and place these functions in the updatable code area.Figure 6
Layout of memory.The function is the minimum component that can be updated by the dynamic software update in part. Taking advantage of the compiler’s ability to assign the compiled code to a designated address, we put each function that needs update separately in a self-defined program section. The self-defined program section is physically mapped to the updatable code area. According to the estimated number of functions that may need to be updated, we partition the updatable code area to make it convenient to store the updated program.Once the patch file is received by the microcontroller of artificial organs via Wireless Body Area Networks (WBAN) [35], it will be parsed and safety-checked. After the program is burnt into the designated memory, the corresponding function pointer will be modified so that the application program can use the newly updated function. The framework of the dynamic software update in part is shown in Figure 7.Figure 7
Framework of the partial dynamic software update.We designed a rollback mechanism to improve reliability. When the data verification or program burning fails, the update will be stopped and the previous version of the program will be reloaded so that the program continues to run the old version of the program.


## 5.1. Power Management Service

Based on the low power modes of the microcontroller, Cyborgan OS implements a power management service that enables the operating system to switch between run mode, sleep mode, and stop mode and takes the task wake-up alignment to further alleviate the impact of task switch on system power consumption [34].


### 5.1.1. System Operation Optimization

In an embedded RTOS, a task is generally activated by event-based triggers or time-based triggers. In the event-based triggering, a task is activated when corresponding event such as an interrupt takes place. After the task is completed, the operating system performs the idle task and waits for the next event to trigger another task. The time-based triggering makes use of the alarm mechanism to periodically activate certain tasks. When the task is executed, the operating system will again perform the idle task. In the SmartOSEK OS, the idle task will do nothing except incrementing an uint8 variable in an infinite loop, which is a waste of system resources.To avoid this waste, the Cyborgan OS will automatically switch to the sleep mode when the idle task is activated. When it needs to terminate the idle task and to perform other tasks, it will automatically switch to the run mode. Assuming that the idle task occupies 50% of the CPU time and the current in the run mode and in the sleep mode is 4 mA and 0.1 mA, respectively, after taking this mode-switching method, the average current is reduced from 4 mA to 2.05 mA, and the power consumption drops by 48.8%, which are significant advances.


### 5.1.2. Task Wake-up Alignment

In the implementation of the Cyborgan OS, the system tick is triggered by the alarm interrupt and is triggered every 1 ms in the default setting. When the system enters the sleep mode, even if there is no user interrupts tasks to be handled, the system tick will make the operating system switch from the sleep mode to the run mode every 1 ms. Figure5(a) shows the interference from the system tick with the system operation. In [27] tickless idle technique is implemented in FreeRTOS to solve this problem. As shown in Figure 5(b), the tickless idle implies disabling the tick sourced from the idle task function, in order to ensure that the processor remains in the low power mode for longer periods of time. At the moment of entering the low power mode, the information of when a user task has to continue execution is obtained from the delayed task list and is used for the configuring of the timer to generate interrupt and wake up processor just before the task has to be deblocked.Figure 5
Operating system run/sleep mode switch using three strategies: (a) no optimization, (b) tickless idle technique, and (c) task wake-up alignment.(1)
No optimization will bring unnecessary interruptions caused by the system tick, since the system tick changes the value of the timer by the interrupt. Even if there is no user task, it will leave the sleep mode due to the system tick interrupt. Taking this strategy, the power consumption (Pc) is(1)Pc=t1+t2+t3+tTick×tickCnt×a1+tSleep×a2+tickCnt+3×2×a3.(2)
Applying the tickless idle technique, the system tick is temporarily disabled when the system enters the sleep mode and a general-purpose timer clocked with the system clock is used. So unnecessary system tick interrupts will not be generated in the sleep mode, and the power consumption is(2)Pc=t1+t2+t3×a1+tSleep×a2+3×2×a3.(3)
On the basis of the tickless idle technique, the task wake-up alignment further reduces the number of switches between the run mode and the sleep mode. The power consumption is(3)Pc=t1+t2+t3×a1+tSleep×a2+2×a3.In the scenario of artificial organs, most tasks are periodic, so it suffices to trigger them periodically. For this reason, this paper proposes the task wake-up alignment to optimize the system. The task wake-up alignment implies waking up for execution at the same time those tasks need to be waken up. As shown in Figure5(c), when the period of one task is multiple that of another, we can select a time interval and wake up the tasks periodically. After each wake-up, the waken up tasks are triggered and executed in batch. After completing these tasks, the operating system performs the idle task and enters the sleep mode. Compared with the tickless idle technique, the wake-up alignment can further reduce the number of wake-ups and hence the power consumption.As shown in Figure5, Task1, Task2, and Task3 are needed to be waken up during period T. t1, t2 and t3 represent the execution time of Task1, Task2, and Task3, respectively. tSleep represents the time the system is in sleep mode. tTick represents the execution time of each system tick. tickCnt represents the number of ticks in period T. It is assumed that the current is a1 in the run mode, a2 in the sleep mode, and a3 during the mode switch. The three different strategies are analyzed in detail as follows:From the above analysis, we conclude that the task wake-up alignment can achieve lower power consumption.


## 5.1.1. System Operation Optimization

In an embedded RTOS, a task is generally activated by event-based triggers or time-based triggers. In the event-based triggering, a task is activated when corresponding event such as an interrupt takes place. After the task is completed, the operating system performs the idle task and waits for the next event to trigger another task. The time-based triggering makes use of the alarm mechanism to periodically activate certain tasks. When the task is executed, the operating system will again perform the idle task. In the SmartOSEK OS, the idle task will do nothing except incrementing an uint8 variable in an infinite loop, which is a waste of system resources.To avoid this waste, the Cyborgan OS will automatically switch to the sleep mode when the idle task is activated. When it needs to terminate the idle task and to perform other tasks, it will automatically switch to the run mode. Assuming that the idle task occupies 50% of the CPU time and the current in the run mode and in the sleep mode is 4 mA and 0.1 mA, respectively, after taking this mode-switching method, the average current is reduced from 4 mA to 2.05 mA, and the power consumption drops by 48.8%, which are significant advances.


## 5.1.2. Task Wake-up Alignment

In the implementation of the Cyborgan OS, the system tick is triggered by the alarm interrupt and is triggered every 1 ms in the default setting. When the system enters the sleep mode, even if there is no user interrupts tasks to be handled, the system tick will make the operating system switch from the sleep mode to the run mode every 1 ms. Figure5(a) shows the interference from the system tick with the system operation. In [27] tickless idle technique is implemented in FreeRTOS to solve this problem. As shown in Figure 5(b), the tickless idle implies disabling the tick sourced from the idle task function, in order to ensure that the processor remains in the low power mode for longer periods of time. At the moment of entering the low power mode, the information of when a user task has to continue execution is obtained from the delayed task list and is used for the configuring of the timer to generate interrupt and wake up processor just before the task has to be deblocked.Figure 5
Operating system run/sleep mode switch using three strategies: (a) no optimization, (b) tickless idle technique, and (c) task wake-up alignment.(1)
No optimization will bring unnecessary interruptions caused by the system tick, since the system tick changes the value of the timer by the interrupt. Even if there is no user task, it will leave the sleep mode due to the system tick interrupt. Taking this strategy, the power consumption (Pc) is(1)Pc=t1+t2+t3+tTick×tickCnt×a1+tSleep×a2+tickCnt+3×2×a3.(2)
Applying the tickless idle technique, the system tick is temporarily disabled when the system enters the sleep mode and a general-purpose timer clocked with the system clock is used. So unnecessary system tick interrupts will not be generated in the sleep mode, and the power consumption is(2)Pc=t1+t2+t3×a1+tSleep×a2+3×2×a3.(3)
On the basis of the tickless idle technique, the task wake-up alignment further reduces the number of switches between the run mode and the sleep mode. The power consumption is(3)Pc=t1+t2+t3×a1+tSleep×a2+2×a3.In the scenario of artificial organs, most tasks are periodic, so it suffices to trigger them periodically. For this reason, this paper proposes the task wake-up alignment to optimize the system. The task wake-up alignment implies waking up for execution at the same time those tasks need to be waken up. As shown in Figure5(c), when the period of one task is multiple that of another, we can select a time interval and wake up the tasks periodically. After each wake-up, the waken up tasks are triggered and executed in batch. After completing these tasks, the operating system performs the idle task and enters the sleep mode. Compared with the tickless idle technique, the wake-up alignment can further reduce the number of wake-ups and hence the power consumption.As shown in Figure5, Task1, Task2, and Task3 are needed to be waken up during period T. t1, t2 and t3 represent the execution time of Task1, Task2, and Task3, respectively. tSleep represents the time the system is in sleep mode. tTick represents the execution time of each system tick. tickCnt represents the number of ticks in period T. It is assumed that the current is a1 in the run mode, a2 in the sleep mode, and a3 during the mode switch. The three different strategies are analyzed in detail as follows:From the above analysis, we conclude that the task wake-up alignment can achieve lower power consumption.


## 5.2. Partial Dynamic Software Update Service

The application scenario of artificial organs poses two challenges for designers of software update: (1) how to update the program without affecting the system’s normal functioning? (2) If the update fails, how to do the version rollback of the program? To solve these two questions, this paper proposes a partial dynamic software update service.The key of partial dynamic software update lies in the incremental update and rollback mechanism, which means that every single update targets only one function, burning in the new version of the function to replace the old one. Each function that needs to be updated is placed in a predefined program section, ensuring that the update is performed at the function level.Partial dynamic software update divides the microcontroller’s memory into a fixed code area and updatable code area, as shown in Figure6. The kernel of the operating system resides in the fixed code area since it is not allowed to modify the kernel of the operating system. In the early stage of designing the application software for the artificial organs, it is necessary to estimate which functions may need to update afterward and place these functions in the updatable code area.Figure 6
Layout of memory.The function is the minimum component that can be updated by the dynamic software update in part. Taking advantage of the compiler’s ability to assign the compiled code to a designated address, we put each function that needs update separately in a self-defined program section. The self-defined program section is physically mapped to the updatable code area. According to the estimated number of functions that may need to be updated, we partition the updatable code area to make it convenient to store the updated program.Once the patch file is received by the microcontroller of artificial organs via Wireless Body Area Networks (WBAN) [35], it will be parsed and safety-checked. After the program is burnt into the designated memory, the corresponding function pointer will be modified so that the application program can use the newly updated function. The framework of the dynamic software update in part is shown in Figure 7.Figure 7
Framework of the partial dynamic software update.We designed a rollback mechanism to improve reliability. When the data verification or program burning fails, the update will be stopped and the previous version of the program will be reloaded so that the program continues to run the old version of the program.


## 6. The Application of Cyborgan OS

In this paper, we instantiate the operating system based on NXP KL02 microcontroller, which only has 32 kB ROM and 4 kB RAM. To verify the feasibility of the Cyborgan OS for artificial organs, this paper tests it in a heart-blood pump model. The heart-blood pump model uses an artificial blood pump to replace the ventricle. The model can perform respiratory monitoring, temperature monitoring and blood pump control, etc. When the patient’s respiratory rate changes, the blood pump output is controlled in real-time. Closed-loop control is realized in this heart-blood pump model. Figure8 is a picture of the heart-blood pump model.Figure 8
Heart-blood pump model.


### 6.1. Hardware Framework

In the heart-blood pump model, the blood pump control node (KL02-A) and the sensor acquisition node (KL02-B) are responsible for the control and data acquisition of all the peripherals. Both nodes run Cyborgan OS and communicate with each other by the I2C bus. The hardware framework is shown in Figure 9.Figure 9
Hardware framework of the heart-blood pump model.


### 6.2. Application Software Design

According to the improved method mentioned above, we optimize the task allocation, make it run serially, and reduce the time of context switching. As shown in Figure10, task OsTaskRecv and OsTaskCtrl run on KL02-A, in which OsTaskRecv receives the sensor data sent from KL02-B and OsTaskCtrl controls the blood pump. They are activated in a sequence of 100 ms cycles. Three tasks named OsTaskTemp, OsTaskRate, and OsTaskSend run on KL02-B, which are responsible for body temperature, respiratory rate acquisition, and sensor data transmission to KL02-A. According to the task wake-up alignment strategy, the OS activates these three tasks in sequence every 100 ms too.Figure 10
Task execution sequence on two nodes.When the blood pump is in normal operation, it pumps about 73 times/minute. If the respiratory rate or body temperature is too high, the blood pump control state will switch into an emergency state and gradually increase its pumping frequency. When exiting from the emergency state, the blood pump will gradually lower its pumping frequency in the same way, finally returning to 73 times/minute.We used the CodeWarrior development environment to integrate the application code running on KL02-A and KL02-B with the Cyborgan OS source files into a project. Then we compile and link this project to generate the object code ELF files. Finally, the ELF file is parsed with the greadelf tool to get the sizes of data segments, as shown in Table1.Table 1
Sizes of data segments of the ELF files generated in the heart-blood pump model.
SegmentKL02-A (byte)KL02-B (byte).text1324011040.data5666.bss19322508As can be seen from Table1, Cyborgan OS is lightweight enough to run on the KL02 platform with very limited resources.


## 6.1. Hardware Framework

In the heart-blood pump model, the blood pump control node (KL02-A) and the sensor acquisition node (KL02-B) are responsible for the control and data acquisition of all the peripherals. Both nodes run Cyborgan OS and communicate with each other by the I2C bus. The hardware framework is shown in Figure 9.Figure 9
Hardware framework of the heart-blood pump model.


## 6.2. Application Software Design

According to the improved method mentioned above, we optimize the task allocation, make it run serially, and reduce the time of context switching. As shown in Figure10, task OsTaskRecv and OsTaskCtrl run on KL02-A, in which OsTaskRecv receives the sensor data sent from KL02-B and OsTaskCtrl controls the blood pump. They are activated in a sequence of 100 ms cycles. Three tasks named OsTaskTemp, OsTaskRate, and OsTaskSend run on KL02-B, which are responsible for body temperature, respiratory rate acquisition, and sensor data transmission to KL02-A. According to the task wake-up alignment strategy, the OS activates these three tasks in sequence every 100 ms too.Figure 10
Task execution sequence on two nodes.When the blood pump is in normal operation, it pumps about 73 times/minute. If the respiratory rate or body temperature is too high, the blood pump control state will switch into an emergency state and gradually increase its pumping frequency. When exiting from the emergency state, the blood pump will gradually lower its pumping frequency in the same way, finally returning to 73 times/minute.We used the CodeWarrior development environment to integrate the application code running on KL02-A and KL02-B with the Cyborgan OS source files into a project. Then we compile and link this project to generate the object code ELF files. Finally, the ELF file is parsed with the greadelf tool to get the sizes of data segments, as shown in Table1.Table 1
Sizes of data segments of the ELF files generated in the heart-blood pump model.
SegmentKL02-A (byte)KL02-B (byte).text1324011040.data5666.bss19322508As can be seen from Table1, Cyborgan OS is lightweight enough to run on the KL02 platform with very limited resources.


## 7. Conclusion

With the increasing complexity of artificial organs, embedded real-time operating system as its basic software platform becomes inevitable. However, due to the limitations of the physical space of artificial organs, hardware resources are limited. Therefore, code size, low power consumption, and partial dynamic software update have become the three key points of artificial organ operating systems. According to the application scenario of artificial organ, this paper puts forward the design principle and structure of artificial organ operating system. According to these principles, Cyborgan OS reduces the code size of the kernel without sacrificing the basic performance, implements a low-power strategy, and adopts the partial dynamic software update method. The operating system has the characteristics of real-time, low power consumption, and small code space, which will be further extended to the other fields of Internet of things and edge computing in the future.



---

*Source: 8871626-2020-10-14.xml*