Content area
The paper presents a real-time operating system (RTOS) that provides a distributed shared memory (DSM) service for distributed embedded control systems. Model-based design is widely adopted in embedded control software design and the source code of software modules can be generated from a controller model. The generated software modules exchange their input and output values through shared variables. We develop a RTOS with a DSM service to provide a location-transparent environment, in which distributed software modules can exchange input and output values through the DSM. The RTOS is an extension to OSEK OS. We use a real-time network called FlexRay, which is based on a time division multiple access (TDMA) protocol. The consistency of the DSM is maintained according to the order of data transfer through FlexRay, not using inter-node synchronization. The worst case response time of the DSM is predictable if the FlexRay communication is well configured.
Introduction
An application program of an embedded control system is designed as a set of software modules. For example, an automotive engine control application program consists of a number of software modules for fuel injection, ignition, emission control and diagnosis. The software modules are executed by tasks on a real-time operating system (RTOS). For example, OSEK OS [1], a de facto standard operating system presented by OSEK/VDX, is widely used in automotive control systems.
Model-based design is widely adopted in embedded control software design, especially in the domain of automotive control design. In model-based design, a controller model is designed and verified using a model-based design tool such as MATLAB/Simulink [2]. The source code of software modules can be generated from the controller model by a code generator such as Real-Time Workshop/Embedded Coder [2]. The generated software modules exchange their input and output values through global variables.
Distributed embedded control systems are used in the domains of automotive control, factory automation, building control, and so on. Time predictability is one of the most important issues for design of distributed automotive control systems [3]. Real-time and location-transparent distributed computing environments are required.
Message-based communication environments are used in distributed embedded control systems. For example, OSEK COM [4], a de facto standard communication environment presented by OSEK/VDX, is widely used in automotive control systems. Messages of OSEK COM are represented as message objects. An application program sends a message by calling SendMessage() and receives a message by calling ReceiveMessage(). If we build a distributed control system with software modules developed by model-based design on a message-based communication environment, we have to rewrite the generated source code to exchange input and output values by messages, not global variables.
Distributed shared memory (DSM) provides location-parent shared variables, so distributed software modules developed by model-based design can exchange their input and output values through shared variables on DSM. However, existing DSM systems are not suitable for embedded control systems. Most DSM systems are based on page-based DSM [5, 6]. The response time of page-based DSM is difficult to predict in a distributed computing environment. It is also difficult to implement a page-based based DSM mechanism in a small RTOS with no virtual memory on a microcontroller without memory management unit (MMU), which is widely used in embedded control systems.
There are a few researches on DSM that requires neither virtual memory nor MMU. Schmidt et al. presented DSM [7] for automotive environments with Controller Area Network (CAN) [8], which is a standard network protocol in the automotive control domain. However, the DSM supports just multiple reader/single writer situations. DSM that supports multiple reader/multiple writer situations is required. Piotrowski et al. presented a middleware called tinyDSM for wireless sensor networks (WSN) [9], which can be used for integrating WSN and cloud computing [10]. tinyDSM, however, cannot be applied to hard real-time control systems such as automotive control systems, for which the worst case response time must be predictable. Jiang et al. presented DSM for coordination among mobile robots [11]. The DSM provides Read and Write interfaces of shared registers on DSM for applications. The interfaces are object-oriented access methods. So, application programs with direct access to shared variables have to be rewritten for the interface.
The goal of the research is to develop a RTOS with DSM for embedded distributed control systems. To achieve the goal, we present a real-time DSM service suitable for distributed embedded control systems with software modules generated from Simulink models.
We have already presented a distributed RTOS with DSM [12] as an extension to OSEK OS. The RTOS utilizes a time division multiple access (TDMA)-based real-time network called FlexRay [13] and the DSM supports a consistency model called partially-sequential consistency, which is weaker than sequential consistency [14]. We present a stronger consistency model called equivalently-sequential consistency, which is equivalent to sequential consistency in case that periodically executed control software modules designed by model-based design tools share variables on the DSM. We also extend the DSM of RTOS to support equivalently-sequential consistency.
The rest of the paper is organized as follows. Section 2 describes DSM models for embedded control software. Section 3 describes the details of the RTOS with DSM. Section 4 describes implementation and experimental evaluation of the DSM. Section 5 concludes the paper.
Distributed shared memory for embedded control systems
Distributed control software
A controller model built with MATLAB/Simulink is a layered model. According to the modeling guidelines presented by Mathworks Automotive Advisory Board (MAAB) [15], a controller model consists of the top layer, the trigger layer (optional), the structure layer and the dataflow layer. A structure layer model represents the structure of a controller model, which is a set of subsystem blocks. A data flow layer model represents detailed control logic (control algorithm). The source code of a software module is generated from a subsystem block of a controller model.
Figure 1 illustrates a part of an example structure layer model, which consists of SubsystemX, SubsystemY, SubsystemZ and SubsystemW. The signal line from output x of SubsystemX is connected to input x of SubsystemZ and input x of SubsystemW. The signal line from output y of SubsystemY is also similar. The signal line from output z of SubsystemZ is connected to input z of SubsystemW.
Fig. 1 [Images not available. See PDF.]
Example Simulink model
Fig. 2 [Images not available. See PDF.]
Example control software
Figure 2 illustrates the structure of an example control software corresponding to the model shown by Fig. 1. SubsystemX, SubsytemY, SubsystemZ and SubsystemW are respectively executed by Task1, Task2, Task3 and Task4. SubsystemX reads and writes the value of global variable x and SubsystemY writes the value of global variable y. SubsytemZ reads the value of x and the value of y and writes the value of global variable z. SubsystemW read the value of x and the value of y and the value of z.
Mutual exclusion is generally needed to access a global variable in a preemptive multi-task environment. For example, OSEK OS provides resource access system calls for mutual exclusion: GetResource() and ReleaseResource(). To accesses a global variable that are shared with another task, the task calls GetResource() before the access and calls ReleaseResource() after the access.
Software modules corresponding to subsystem blocks are distributed to a number of nodes in a distributed embedded control system. Figure 3 illustrates the structure of an example distributed control software with DSM. Software modules generated from the Simulink model shown by Fig. 1 are distributed to four nodes.
Fig. 3 [Images not available. See PDF.]
Example distributed control software
SubsystemX, SubsytemY, SubsytemZ and SubsytemW are respectively executed by Task11 on Node1, Task21 on Node2, Task31 on Node3 and Task41 on Node4. The copies of shared variable x are located on Node1, Node3 and Node4. The copies of shared variable y are located on Node2, Node3 and Node4. The copies of shared variable z are located on Node3 and Node4. The consistency of the shared variables is maintained by the DSM service of the RTOS.
We call a task that performs just read operations to a shared variable a reader task, call a task that performs just write operations to a shared variable a writer task, and call a task that performs both read and write operations to a shared variable a reader-writer task. For example, Task11 is a reader-writer task of x, Task21 is a writer task of y, Task31 is a reader task of x and y and a writer task of z, and Task41 is a reader task of x, y and z in Fig. 3.
There are three kinds of DSM models: single reader/single writer (SRSW) model, multiple reader/single writer (MRSW) model and multiple reader/multiple writer (MRMW) model [6]. A signal line of a Simulink model is connected to just one output of a subsystem block and connected to one or more inputs of other subsystem blocks. So the MRSW model usually fits the distributed software modules generated from Simulink models.
The MRMW model of DSM may be needed when a single shared variable is used for a special block that connects a number of signal lines. For example, Fig. 4 illustrates a Simulink model with a Merge block, which merges the output signal lines of SubsystemX1 and SubsystemX2. The merged signal line is connected to the inputs of SubsystemY and SubsystemZ. If SubsystemX1 and SubsystemX2 just perform write operations to x, SubsystemX1, SubsystemX2, SubsystemY and SubsystemZ can be connected with a shared variable corresponding to x.
Fig. 4 [Images not available. See PDF.]
Example Simulink model with merge block
Figure 5 illustrates the structure of an example distributed control software for the Simulink model shown by Fig. 4. Shared variable x is used to store both the output value of SubsystemX1 and the output value of SubsystemX2. The MRMW model of DSM is needed in this case because both Task11 and Task21 perform write operations to x. So we support not only the MRSW model but also the MRMW model. However, note that a single shared variable can not be used if either SubsystemX1 or SubsystemX2 performs both read and write operations to x because the calculation of SubsystemX1 and the calculation of SubsystemX2 must be executed independently.
Fig. 5 [Images not available. See PDF.]
Example distributed control software with multiple writers
Design policies of DSM
We present a DSM mechanism based on a shared-variable DSM architecture [5], not a page-based DSM architecture, because only certain variables are shared in distributed control software developed with MATLAB/Simulink.
The design policies of the DSM are shown below [12].
MMU should not be used because most microcontrollers used in embedded control systems have no MMU.
Inter-node synchronization should not be used because it may cause a performance problem (intra-node synchronization (inter-task synchronization) is acceptable).
No new API of RTOS for DSM is required because new API may violate the compatibility (an extension of the semantics of an API is acceptable).
Consistency sufficient for the control software generated from Simulink models should be provided.
Consistency model
Some consistency models for DSM have been presented [5, 6, 16]. Sequential consistency [14] is the strongest consistency other than strict consistency. Sequential consistency maintains so that the same write operation sequence is observed by all nodes. However, complete sequential consistency is not needed for the control software generated from Simulink models.
The software modules generated from a Simulink model are cyclically executed. Input and output values are not events but states. One-to-one synchronization between a writer task and a reader task is not required, because the reader task can read the shared variable many times or not at all. The written value may be overwritten before being read by the reader task. This may seem that a write operation is missed. So, complete sequential consistency is not needed.
The semantics of the consistency model of the DSM is similar to the semantics of the state message [17]. The state message is widely used in message-based distributed control systems. The state message is called unqueued message in OSEK COM [4]. AUTOSAR COM also supports just unqueued messages [18].
We present two consistency models of the DSM: partially-sequential consistency and equivalently-sequential consistency. The former maintains the write operation sequence for each shared variable and the latter maintains the write operation sequence for all shared variables.
To realize the consistency models not using inter-node synchronization, we present a method that inhibits a read operation after a write operation to a shared variable until the data transfer of the shared variable is completed or until other nodes receives the data. If the task tries to read immediately after the write operation, the state of the task is changed to state waiting until the inhibition is removed. The inhibition is needed just for reader-writer tasks, not for writer tasks or reader tasks, as shown later.
The consistency is maintained according to the sequence of data transfer through FlexRay. FlexRay communication is periodically performed with a communication cycle. The RTOS receives the transferred data by cyclic polling, not by interrupt, to reduce overheads.
Figure 6 illustrates an example DSM access sequence in the case of Fig. 3. The operations performed by a task on each node are shown horizontally, with time increasing to the right. The notation r(x,a) means that a task reads the value a from the variable x. The notation w(x,b) means that b task writes the value b into the variable x.
Fig. 6 [Images not available. See PDF.]
Example DSM access sequence
The value of a shared variable written by a task is transferred to other nodes through FlexRay. The notation t(x,b) in Fig. 6 means that the value b of the variable x is transferred through FlexRay. The transferred value is received and written into the copy of the shared variable in each node at the beginning of the communication cycle. In Fig. 6, the value b of the variable x sent by Task11 on Node1 is transferred during the nth cycle and received by Task31 on Node3 and Task41 on Node4 at the beginning of the n+1th cycle. The value q of the variable y sent by Task21 on Node2 during the nth cycle is transferred during the n+1th cycle and received by Task31 on Node3 and Task41 on Node3 at the beginning of the n+2th cycle.
Partially-sequential consistency is realized by inhibiting a read operation until the data transfer completes. After writing t into z, Task31 cannot read z until the data transfer is completed in this case. The same write operation sequence for the variable z is observed by every node. However, the different write operation sequences for all shared variables may be observed by nodes.
Equivalently-sequential consistency is realized by inhibiting a read operation until the next communication cycle. After writing t into z, Task31 cannot read z until the data is received by other nodes in this case. The same write operation sequence is observed by every node as follows: w(x,b), w(y,q), w(z,t), w(x,c).
Figure 7 illustrates an example DSM access sequence in the case of Fig. 5, which is a case of MRMW. Task11 on Node1 and Task21 on Node2 are writer tasks, not reader-writer tasks, so no access inhibit interval is needed. Task12 on Node1 and Task22 on Node2 observe that the write operations to x by Task11 on Node1 and by Task21 on Node2 are performed in the same order. So, the same write operation sequence is observed by every node as follows: w(x,b), w(x,c), w(x,d).
Fig. 7 [Images not available. See PDF.]
Example MRMW DSM access sequence
Fig. 8 [Images not available. See PDF.]
Inhibit intervals and task period
We assume the FlexRay communication cycle period is sufficiently shorter than the periods of application tasks. The typical FlexRay communication cycle is 1 ms and the typical period of automotive application tasks is 10 ms or longer. So the access inhibit intervals are also sufficiently shorter than the interval time from the write operation to the next cycle’s read operation performed by periodic tasks. The inhibition does not influence the behavior of the application in most cases.
Figure 8 illustrates the an example execution sequence of Task31 shown in Fig. 6 in the case that the period of Task31 is 10 ms and the FlexRay communication cycle is 1 ms. Task31 is activated at time 10 and time 20. Task31 writes t into z during time 11 to time 12 and cannot read z until time 13 in the case of equivalently-sequential consistency. However, the next write operation by Task31 is not performed before the next job of Task is activates at time 20. So the inhibition does not influence the behavior of Task31.
If multiple data transfers for the same shared variable are performed during one communication cycle (this rarely occurs because of the above assumption), just the value of the last transfer is received. This is not a problem because it looks like the write operations are performed consecutively.
API of distributed shared memory
OSEK OS provides resource management system calls for mutual exclusion: GetResource() and ReleaseResource(). To access a global variable that are shared with another task, the task calls GetResource() to enter the critical section and calls ReleaseResource() to leave the critical section.
We extend the semantics of the resource management system calls and use them to access shared variables on the DSM. A set of distributed shared variables is dealt with as a distributed shared resource. When a task accesses a distributed shared variable, the task calls GetResource() before the access and calls ReleaseResource() after the access. Inter-node mutual exclusion is, however, not supported as described in Sect. 2.2. Inter-task mutual exclusion on the same processor is supported.
Figure 9 shows a fragment of example source code of application program. The name of the shared variable is sharedData0 and the identifier of the resource for sharedData0 is ResourceSharedData0. A set of shared variables, not just a shared variable, can be handled as a distributed shared resource. We have to insert system calls GetResource() and ReleaseResource() into the source code generated from Simulink models to utilize DSM. However, mutual exclusion must be also considered even when the software modules are executed in a preemptive multi-task environment on a single processor system.
Fig. 9 [Images not available. See PDF.]
Example source code
The configuration of an OSEK application on OSEK OS is described in OSEK implementation language (OIL) [19]. For example, tasks, events and resources are statically declared in an OIL file. The configuration data of OSEK OS are generated by the system generator (SG).
We extend OIL to declare distributed shared variables. Figure 10 shows an example OIL description. In this example, the shared variable sharedData0 is declared. Its data type is long in C language, its initial value is zero, and equivalently-sequential consistency is selected. The task Task11 on CPU1 shares the shared variable haredData0.
Fig. 10 [Images not available. See PDF.]
Example OIL description
Fig. 11 [Images not available. See PDF.]
Structure of real-time operating system
Real-time operating system
Software structure
We have already developed a RTOS with location-transparent system calls for distributed embedded control systems [20] as an extension to TOPPERS/OSEK kernel, an OSEK-compliant operating system developed by TOPPERS project [21]. The RTOS provides location-transparent system calls for task management and event control. An application task activates or synchronizes with remote tasks using the same APIs as local tasks. The RTOS manages distributed tasks based on the global time, which is supported by the clock synchronization of FlexRay.
We extend the RTOS to support DSM based on the model presented in Sect. 2. We add a distributed shared memory module, which manages the copies of shared variables and maintains the consistency. The copies of shared variables are allocated in the data section of application program on each node.
Figure 11 illustrates the structure of the RTOS, which consists of the OSEK OS original functions, a timer synchronization module, a remote system call module, a distributed shared memory module and configuration data.
The timer synchronization module manages the global time, which is maintained by synchronizing with the network time provided by FlexRay. The remote system call module executes the processing for the remote system call, which calls the system call of the RTOS on another node. The distributed shared memory module manages the copies of shared variables and maintains the consistency. The configuration data consists of the original OSEK configuration data, task location data for remote system calls, and DSM configuration data.
Table 1 shows the OSEK OS system calls for task management, event control and resource management. The column Extension of Table 1 shows whether the system call is extended for remote system calls or for DSM. Remote means that the system call is extended to be a remote system call. DSM means that the system call is extended to be used for DSM. No means that the system call is not extended. The parameters Task, Event and Resource means the task ID, the event mask and the resource ID respectively. The parameters TaskRef, StateRef and EventRef mean the variables to store the task ID, the task status and the event mask.
Table 1. OSEK OS system calls for task management and event control
Category | API | Extension |
|---|---|---|
Task management | ActivateTask(Task) | Remote |
TerminateTask() | No | |
ChainTask(Task) | Remote | |
Schedule() | No | |
GetTaskID(TaskRef) | No | |
GetTaskStatus(Task, StateRef) | Remote | |
Event control | SetEvent(Task, Event) | Remote |
ClearEvent(Event) | No | |
GetEvent(Task, EventRef) | Remote | |
WaitEvent(Event) | No | |
Resource management | GetResorce(Resource) | DSM |
ReleaseResorce(Resource) | DSM |
The communication cycle of FlexRay is divided into the static segment for periodic messages and the dynamic segment for event-triggered messages. The messages of remote system calls and DSM are transmitted in the dynamic segment because system calls and DSM accesses are eventually performed.
Distributed shared memory mechanism
This section describes the details of the DSM mechanism of the RTOS. The copies of shared variables are allocated in the data section of application program on each node. We add DSM functionalities to GetResource() and ReleaseResource(). We call the former DSM access pre-processing and the latter DSM access post-processing. The RTOS on each node has shared data buffers and received data buffers.
Figure 12 shows a time chart of the DSM processing on the writer node. When the application task calls GetResource() before accessing to a shared variable, the RTOS executes the processing of the original GetResource() of OSEK. Then, the RTOS determines if the resource is a DSM resource or not. If the resource is a DSM resource, the RTOS executes the DSM access preprocessing, which copies the value of the shared data buffer to the shared variable.
Fig. 12 [Images not available. See PDF.]
Time chart of writer node processing
When the application task calls ReleaseResource() after accessing to the shared variable, the RTOS determines if the resource is a DSM resource or not. If the resource is a DSM resource, the RTOS executes the DSM access postprocessing. The DSM access postprocessing compares the value of the shared variable and the value of the shared data buffer, and calls the FlexRay driver to send the former value if the values are different. Then the RTOS executes the processing of the original ReleaseResource() of OSEK OS. When the FlexRay controller completes the data transfer, an interrupt occurs. The interrupt executes DSM buffer update, which copies the value of the shared variable to the shared data buffer.
Figure 13 shows a time chart with an access inhibit interval for partially-sequential consistency. When the application task (reader-writer task) calls GetResource() before the FlexRay controller completes the data transfer, the RTOS changes the state of the task to waiting. When the FlexRay controller completes the data transfer, the interrupt checks the state of the task is waiting or not. If the state of the task is waiting, the interrupt changes the state of the task to ready. This is implemented using the event mechanism of OSEK OS.
Fig. 13 [Images not available. See PDF.]
Time cart with access inhibit interval in partially-sequential consistency
Figure 14 shows a time chart with an access inhibit interval for equivalently-sequential consistency. When the application task callsGetResource() before completing the communication cycle during which the data transfer is performed, the RTOS changes the state of the task to waiting. The cycle start processing of the next communication cycle changes the state of the task to ready. The task state change is performed by the cycle start processing in equivalently sequential consistency, not by the data transfer completion interrupt.
Fig. 14 [Images not available. See PDF.]
Time cart with access inhibit interval in equivalently-sequential consistency
Figure 15 shows a time chart of the DSM processing on the reader node in the case that no task holds the DSM resource. In this case, the received data update processing writes the received value into both the received data buffer and the shared data buffer. When the application task calls GetResource() before accessing to a shared variable, the RTOS determines if the resource is a DSM resource or not. If the resource is a DSM resource, the RTOS executes DSM access preprocessing, which copies the value of the shared data buffer to the shared variable as described before. Then the application task reads the value from the shared variable.
Fig. 15 [Images not available. See PDF.]
Time chart of reader node processing in Case 1
Fig. 16 [Images not available. See PDF.]
Time chart of reader node processing in Case 2
Fig. 17 [Images not available. See PDF.]
Response time of distributed share memory
Table 2. Execution time of DSM mechanism
Processing | Execution time (s) | |||||
|---|---|---|---|---|---|---|
1 byte | 2 bytes | 4 bytes | 8 bytes | 16 bytes | ||
DSM access preprocessing | 1.2 | 1.2 | 1.4 | 1.7 | 2.3 | |
DSM access with data transfer | 10.7 | 10.8 | 11.0 | 11.3 | 11.9 | |
Post-processing without data transfer | 1.3 | 1.4 | 1.6 | 2.1 | 2.9 | |
Cycle start processing | 31.9 | 32.0 | 32.2 | 32.5 | 33.1 | |
Received data update | 1.5 | 1.5 | 1.7 | 2.0 | 2.6 | |
DSM buffer update | 1.6 | 1.7 | 1.8 | 2.2 | 2.8 | |
Figure 16 shows a time chart in the case that there is a task that holds the DSM resource. In this case, the received data update processing writes the received value into just the received data buffer. When the application task calls ReleaseResource(), the RTOS executes the DSM access postprocessing, which copies the value of the received data buffer to the shared data buffer.
Response time of distributed shared memory
FlexRay communication parameters are statically designed. Design and analysis methods for FlexRay communication have been presented [22, 23]. FlexRay communication parameters must be designed considering frames for both the RTOS and the application program. The frames for the RTOS is determined by considering the maximum rate of DSM write operations and remote system calls performed in a communication cycle period. The maximum communication delay time is predictable if FlexRay communication is well configured, and so the response time of a DSM service is predictable.
In the example time chart shown by Fig. 12, the data transfer after the write operation is performed in the same communication cycle as the DSM access postprocessing is executed. However, the data transfer may be postponed to the next communication cycle. Figure 17 shows a time chart of the case that the data transfer is postponed. This is the worst case because the data transfer is not postponed to the next to the next communication cycle if the FlexRay communication is well configured.
The response time of the DSM service consists of the DSM access postprocessing execution time, the FlexRay communication delay time, the cycle start processing execution time and the received data update execution time. In the worst case, the maximum total time of the DSM access postprocessing execution time and the FlexRay communication delay time is twice the communication cycle period. So the worst case response time is the total of twice the communication cycle period, the cycle start processing execution time and the received data update execution time. It is about twice the communication cycle period because the cycle start processing execution time and the received data update execution time are sufficiently less than the communication cycle period.
Implementation and experimental evaluation
We have developed the RTOS on a evaluation board called GT200N10, the CPU of which is V850E/PH03 with an on-chip E-Ray FlexRay controller. The clock rate of the CPU is 128 MHz. The data transfer rate of FlexRay is 10 MHz and the communication cycle period is 1 ms.
We have run an evaluation program and measured the CPU execution times of DSM functions: the DSM access preprocessing execution time, the DSM access postprocessing execution time, the cycle start processing execution time, the received data update execution time, and the DSM buffer update execution time. We have measured the execution time using a hardware counter, the clock rate of which is 32 MHz. Table 2 shows the values in cases of the data size of the shared variable is 1 byte, 2, 4, 8 and 16 bytes.
We think each execution time is practically small for automotive control systems. The typical period of the automotive control application periodic tasks is 10 ms or more. The typical event-triggered task of the automotive powertrain control system is a task synchronized with the crankshaft rotation, the period of which is 10 ms when the speed of the crankshaft rotation is 6000 rpm. The typical FlexRay communication cycle period is 1 ms. The dominant factor of the response time of the DSM is the FlexRay communication delay time and the worst case response time is about twice the communication cycle. The worst case response time is about one fifth of the application task period in the typical case, so we think the response time is practically small.
Conclusions
We have presented a RTOS that supports DSM for distributed embedded control systems. The consistency of the DSM is maintained according to the order of data transfer through FlexRay, not using inter-node synchronization. The worst case response time is predictable if the FlexRay communication is well configured. We have also evaluated the performance of the DSM. According to the evaluation results, we think the performance is practically sufficient for automotive control applications.
Acknowledgements
We would like to thank the developers of TOPPERS/ATK1. This work was supported in part by JSPS KAKENHI Grant Numbers JP24500046 and JP15K00084.
References
1. OSEK/VDX, Operating System, Version 2.2.3 (2005)
2. The MathWorks Inc. http://www.mathworks.com/
3. Sangiovanni-Vincentelli, A; Di Natale, M. Embedded system design for automotive applications. IEEE Comput.; 2007; 40,
4. OSEK/VDX, Communication, Version 3.0.3 (2004)
5. Tanenbaum, AS. Distributed Operating Systems; 1995; New Jersey, Prentice Hall:zbMath ID: 0856.68041
6. Protic, J; Tomasevic, M; Milutinovic, V. Distributed shared memory: concepts and systems. IEEE Parallel Distrib. Technol.; 1996; 4,
7. Schmidt, P., Frenz, S., Gerhold, S., Schulthess, P.: Transactional consistency in the automotive environment. In: Proceedings of 2008 International Symposium on Industrial Embedded Systems, pp. 237–240 (2008)
8. Kiencke, U.: Controller Area Network—from concept to reality. In: Proceedings of the 1st International CAN Conference, pp. 11–20 (1994)
9. Piotrowski, K., Langendoerfer, P., Peter S.: tinyDSM: a highly reliable cooperative data storage for wireless sensor networks. In: Proceedings of 2009 International Symposium on Collaborative Technologies and Systems, pp. 225–232 (2009)
10. Langendoerfer, P., Piotrowski, K., Diaz, M. and Rubio, B.: Distributed shared memory as an approach for integrating WSNs and cloud computing. In: Proceedings of 5th International Conference on New Technologies, Mobility and Security, pp. 1–6 (2012)
11. Jiang, X., Huang, Y.: CBBR: Enabling distributed shared memory-based coordination among mobile robots. In: Proceedings of the 7th Asia-Pacific Symposium on Internetware, pp. 11–20 (2015)
12. Chiba, T., Yoo, M., Yokoyama, T.: A distributed real-time operating system with distributed shared memory for embedded control systems. In: Proceedings of the IEEE 11th International Conference on Dependable, Autonomic and Secure Computing, pp. 248–255 (2013)
13. Makowitz, R., Temple, C.: FlexRay—a communication network for automotive control systems. In: Proceedings of the 2006 IEEE International Workshop on Factory Communication Systems, pp. 207–212 (2006)
14. Lamport, L. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Trans. Comput.; 1979; C–28,
15. MathWorks Automotive Advisory Board (MAAB), Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow, Version 3.0 (2012)
16. Adve, SV; Gharachorloo, K. Shared memory consistency models: a tutorial. IEEE Comput.; 1996; 29,
17. Kopetz, H., Merker, W.: The architecture of MARS. In: Proceedings of the 24th International Symposium on Fault-Tolerant Computing, pp. 50–55 (1995)
18. AUTOSAR, Specification of Communication V4.2.0 R4.0 Rev 3 (2011)
19. Osek, V.D.X.: OSEK/VDX system generation OIL: OSEK implementation language version 2, 5 (2004)
20. Chiba, T., Itami, Y., Yoo, M., Yokoyama, T.: A distributed real-time operating system with location-transparent system calls for task management and inter-task synchronization. In: Proceedings of the IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), pp. 1133–1138 (2011)
21. TOPPERS Project. http://www.toppers.jp/en/
22. Pop, T., Pop, P., Eles, P., Peng, Z., Andrei, A.: Timing analysis of the FlexRay communication protocol. In: Proceedings of the 18th Euromicro Conference on Real-Time Systems, pp. 203–216 (2006)
23. Ben, J; Yongming, B; Anhu, L. A method for response time computation in FlexRay communication system. Proc. IEEE Int. Conf. Intell. Comput. Intell. Syst.; 2009; 3, pp. 47-51.
© Springer Science+Business Media, LLC 2017.