A Distributed Real-Time Operating System with Distributed Shared Memory for Embedded Control Systems

Transcription

1 13 IEEE 11th International Conference on Dependable, Autonomic and Secure Computing A Distributed Real- Operating Sstem with Distributed Memor for Embedded Control Sstems Takahiro Chiba, Mungrun Yoo and Takanori Yokoama Toko Cit Universit , Tamazutsumi, Setagaa-ku, Toko Japan Presentl with Sstems Engineering Consultants Co., LTD. chiba@sec.co.jp, {oo, okoama}@cs.tcu.ac.jp Abstract The paper presents a distributed real-time operating sstem () that provides a distributed shared memor (DSM) service for distributed control sstems. Modelbased design has become popular in embedded control software design and the source code of software modules can be generated from a controller model. The generated software modules echange their input and output values through shared variables. We develop a with a real-time DSM service to provide a location-transparent environment, in which distributed software modules can echange input and output values through the DSM. The is an etension to OSEK OS. We use a real-time network called FleRa, which is based on a TDMA ( Division Multiple Access) protocol. The consistenc of the DSM is maintained according to the order of data transfer through FleRa, not using inter-node snchronization. The worst case response time of the DSM is predictable if the FleRa communication is well configured. Kewords-operating sstems; real-time sstems; embedded sstems; distributed shared memor; distributed control sstems; I. INTRODUCTION An application program of an embedded control sstem is designed as a set of software modules. For eample, 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 eecuted b tasks on a real-time operating sstem (RTOS). For eample, OSEK OS [1], a de facto standard operating sstem presented b OSEK/VDX, is widel used in automotive control sstems. Model-based design has become popular in embedded control software design, especiall in the domain of automotive control design. In model-based design, a controller model is designed and verified using a CAD/CAE tool such as MATLAB/Simulink [2]. The source code of software modules can be generated from the controller model b a code generator such as Real- Workshop/Embedded Coder [2]. The generated software modules echange their input and output values through global variables. Distributed embedded control sstems are used in the domains of automotive control, factor automation, building control, and so on. predictabilit is one of the most important issues for design of distributed automotive control sstems [3]. Real-time and location-transparent distributed computing environments are required. Message-based communication environments are used in distributed embedded control sstems. For eample, OSEK COM [4], a de facto standard communication environment presented b OSEK/VDX, is widel used in automotive control sstems. Messages of OSEK COM are represented as message objects. An application program s a message b calling SendMessage() and s a message b calling ReceiveMessage(). If we build a distributed control sstem with software modules developed b model-based design on a message-based communication environment, we have to rewrite the generated source code to echange input and output values b messages, not global variables. Distributed shared memor (DSM) provides locationparent shared variables, so distributed software modules developed b model-based design can echange their input and output values through shared variables on DSM. However, eisting DSM sstems are not suitable for embedded control sstems. Most DSM sstems are based on pagebased 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 memor on a microcontroller without MMU (Memor Management Unit), which is widel used in embedded control sstems. The goal of the research is to develop a distributed realtime operating sstem () with DSM for embedded distributed control sstems. To achieve the goal, we present a real-time DSM service suitable for distributed embedded control sstems with software modules generated from Simulink models. We have al developed a with locationtransparent sstem calls for task management and event control as an etension to OSEK OS [7]. An application task activates or snchronizes with remote tasks using the same APIs as local tasks. The manages distributed tasks based on the global time, which is supported b the /13 $ IEEE DOI.19/DASC

2 z SubsstemX SubsstemZ w SubsstemY SubsstemW Figure 1. Eample Structure Laer of Simulink Model Embedded Computer SubsstemX SubsstemY SubsstemZ SubsstemW write write mutual eclusion Global s RTOS clock snchronization of FleRa [8]. FleRa is a realtime network for automotive control sstems based on a TDMA ( Division Multiple Access) protocol. We add a real-time DSM mechanism to the. The consistenc of the DSM is maintained according to the order of data transfer through FleRa. If the FleRa communication is well configured, the worst case response time of the DSM is predictable. The rest of the paper is organized as follows. Section II describes the DSM model for embedded control software. Section III describes the details of the with DSM. Section IV describes implementation and eperimental evaluation of the DSM. Section V concludes the paper. II. DISTRIBUTED SHARED MEMORY FOR EMBEDDED CONTROL SYSTEMS A. Distributed Control Software A controller model built with MATLAB/Simulink is a laered model. According to the modeling guidelines presented b MAAB (Mathworks Automotive Advisor Board) [9], a controller model consists of the top laer, the trigger laer (optional), the structure laer and the dataflow laer. A structure laer model represents the structure of a controller model, which is a set of subsstem blocks. A data flow laer model represents detailed control logic (control algorithm). The source code a software module is generated from a subsstem block of a controller model. Figure 1 illustrates a part of an eample structure laer model, which consists of SubsstemX, SubsstemY, SubsstemZ and SubsstemW. The signal line from output of SubsstemX is connected to input of SubsstemZ and input of SubsistemW. This means that SubsstemX outputs the value of and SubsustemZ and SubsstemW input the value. The signal line from output of SubsstemY is also similar. Data and data are represented as global variables in the source code generated from the model. Figure 2 illustrates the structure of an eample control software corresponding to the model shown b Figure 1. SubsstemX, SubstemY, SubsstemZ and SubsstemW are respectivel eecuted b 1, 2, 3 and 4. SubsstemX s and writes the value of global variable and SubsstemY writes the value of global variable. SubstemZ and SubsstemW the value of and the SubsstemX Figure 2. Eample Control Software Node3 Node write write s Consistenc Maintenance Figure 3. SubsstemX SubsstemY SubsstemZ Eample Distributed Control Software SubsstemY SubsstemW FleRa write write mutual eclusion s Figure 4. SubsstemZ Consistenc Maintenance SubsstemW FleRa Another Eample Distributed Control Software value of. Mutual eclusion is generall needed to access a global variable in a preemptive multi-task environment. Software modules corresponding to subsstem blocks are distributed to a number of nodes in a distributed embedded control sstem. Figure 3 illustrates the structure of an eample distributed control software with DSM. Software modules generated from the Simulink model shown b Figure 1 are distributed to four nodes. SubsstemX, SubstemY, SubstemZ and SubstemW are respectivel eecuted b 11 on, 21 on, 31 on Node3 and 41 on Node4. The copies of shared variables and are located on the nodes. The consistenc of the shared variables is maintained b the DSM service of the. Figure 4 illustrates the structure of another eample distributed control software. The software modules are distributed to two nodes. SubsstemX and SubstemZ are 249

3 Figure 5. SubsstemX1 SubsstemX2 Merge SubsstemY SubsstemZ Eample Structure Laer of Simulink Model with Merge Block SubsstemX1 Figure 6. write 11 SubsstemY SubsstemX2 write variable Consistenc Maintenance 21 z SubsstemZ FleRa Eample Distributed Control Software with Multiple Writers respectivel eecuted b 11 and 12 on. SubstemY and SubstemW are respectivel eecuted b 21 and 22 on. Mutual eclusion is used between the tasks on the same node. The consistenc of the shared variables between different nodes is maintained b the DSM service of the. We call a task that performs just operations to a shared variable a er task, call a task that performs just write operations to a shared variable a writer task, and call a task that performs both and write operations to a shared variable a er-writer task. For eample, 11 is a er-writer task of, 21 is a writer task of, and 31 and 41 are er tasks of and in Figure 3. There are three kinds of DSM models: single er/single writer (SRSW) model, multiple er/single writer (MRSW) model and multiple er/multiple writer (MRMW) model [6]. A signal line of a Simulink model is connected to just one output of a subsstem block and connected to one or more inputs of other subsstem blocks. So the MRSW model usuall fits the distributed software modules generated from Simulink models. The MRMW model of DSM ma be needed when a single shared variable is used for a special block that connects a number of signal lines. For eample, Figure 5 illustrates a Simulink model with a Merge block, which merges the output signal lines of SubsstemX1 and SubsstemX2. The merged signal line is connected to the inputs of SubsstemY and SubsstemZ. IfSubsstemX1 and SubsstemX2 just perform write operations to, SubsstemX1, SubsstemX2, SubsstemY and SubsstemZ can be connected with a shared variable corresponding to. Figure 6 illustrates the structure of an eample distributed control software for the Simulink model shown b Figure 5. variable is used to store both the output value of SubsstemX1 and the output value of Subsstem2. The MRMW model of DSM is needed in this case because both 11 and 21 perform write operations to. So we support not onl the MRSW model but also the MRMW model. However, note that a single shared variable can not be used if either SubsstemX1 or SubsstemX2 performs both and write operations to because the calculation of SubsstemX1 and the calculation of SubsstemX2 must be eecuted independentl. B. Distributed Memor Model We present a DSM mechanism based on a shared-variable DSM architecture [5], not a page-based DSM architecture, because onl certain variables are shared in distributed control software developed with MATLAB/Simulink. The design policies of the DSM are shown below. MMU should not be used because most microcontrollers used in embedded control sstems have no MMU. Inter-node snchronization should not be used because it ma cause a performance problem (Intra-node snchronization (inter-task snchronization) is acceptable). No new API of for DSM is required because new API ma violate the compatibilit (an etension of the semantics of an API is acceptable). Consistenc sufficient for the control software generated from Simulink models should be provided. The consistenc of the DSM is maintained according to the order of data transfer through FleRa. FleRa communication is periodicall performed with a communication ccle. The s the transferred data b cclic polling, not b interrupt, for the predictabilit of the response time [7]. Some consistenc models for DSM have been presented [5][6][]. Sequential consistenc [11] is the strongest consistenc other than strict consistenc. Sequential consistenc is not needed for the control software generated from Simulink models, but the same sequential order of write operations to the same shared variable is required. We call this partiall-sequential consistenc. To realize the partiall-sequential consistenc model not using inter-node snchronization, we present a method that the net access operation (write or operation) after a write operation to the same shared variable is inhibited until the data transfer for the write operation is completed. If a write operation to a shared variable is performed b a task, the task cannot access the shared variable until its value is transferred to other nodes. Figure 7 illustrates an eample DSM access sequence in the case of Figure 3. The operations performed b a task on each node are shown horizontall, with time increasing to the right. Smbol R()a means that a task s value 250

4 Node3 41 Node4 FleRa access inhibit interval R()a W()b for shared variable W()p R()a R()a T()b T()p n th ccle Communication Ccle Figure 7. R()b R()p n+1 th ccle R()b W()c R()b R()p Eample DSM Access Sequence R()b T()c n+2 th ccle W()q FleRa R()a R()a W()b T()b n th ccle Communication Ccle Figure 9. R()a W()c R()b R()a R()b T()c n+1 th ccle W()b R()b R()c R()c R()c T()d n+2 th ccle Eample MRMW DSM Access Sequence R()d R()c FleRa Figure 8. access inhibit interval R()a W()b for shared variable R()a R()o W()p R()a R()o T()b R()o R()a T()p n th ccle Communication Ccle n+1 th ccle R()b R()b R()p R()b R()p Another Eample DSM Access Sequence a from shared variable. Smbol W()b means that a task writes value a into shared variable. The value of a shared variable written b a task is transferred to other nodes through FleRa. Smbol T()b in Figure 7 means that value b of variable is transferred to other nodes. The transferred value is d and written into the cop of the shared variable in each node at the beginning of the communication ccle. In Figure 7, value b of variable sent b 11 on and value p of variable sent b 21 on during the nth ccle are d b 31 on and 41 on Node3 at the beginning of the n+1th ccle. Partiall-sequential consistenc is realized b the access inhibit interval. In the eample of Figure 7, after 11 on performs R()a and W()b, 11 cannot access until T()b is completed. The access inhibit interval is needed just for er-writer tasks, not for er tasks or writer tasks. Figure 8 illustrates an eample DSM access sequence in the case of Figure 4. W()b b 11 on and W()p b 21 on are performed independentl. 12 on observes that W()b is performed before W()p and 22 on observes that W()p is performed before W()b. Access operations to different shared variables ma be observed in different order. Figure 9 illustrates an eample DSM access sequence in the case of Figure on and 21 on are writer tasks, not er-writer tasks, so no access inhibit interval is needed. 12 on and 22 on observe that the write operations to b 11 on and b 21 on are performed in the same order, for eample, W()b is observed before W()c. The same sequential order of write operations is observed b 12 and 22. We assume the FleRa communication ccle period is sufficientl shorter than the periods of periodic application tasks. The assumption is proper because the tpical FleRa communication ccle is 1msec and the tpical period of automotive application tasks is msec or longer. So the access inhibit intervals are also sufficientl shorter than the interval time between write operations performed b periodic application tasks. If multiple data transfers for the same shared variable are performed during one communication ccle (this rarel occurs because of the above assumption), just the value of the last transfer is d. This is not a problem because it looks like the write operations are performed consecutivel. C. API of Distributed Memor OSEK OS provides resource access sstem calls for mutual eclusion: and ReleaseResource(). When a task accesses a global variable that are shared with another task, the task calls before the access and calls ReleaseResource() after the access. We etend the semantics of the resource management sstem 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 before the access and calls ReleaseResource() after the access. However, inter-node mutual eclusion is not supported as described in Section II-B. Figure shows a fragment of eample source code of application program. The name of the shared variable is shared and the identifier of the resource for shared is Res shared. We have to insert sstem calls and ReleaseResource() into the source code generated from 251

5 /* get the resource for the shared variable */ GetResource(Res_shared_); /* update the shared variable */ shared_ = a * shared_ + b; /* release the resource for the shared variable */ ReleaseResource(Res_shared_); Original Sstem Call OSEK OS Original Functions Figure. CPU An Eample Source Code ECU Program Distributed Real- Operating Sstem Remote Sstem Call r Snchronization Configuration Data FleRa Driver FleRa Controller Distributed Memor FleRa Table I OSEK OS SYSTEM CALLS FOR TASK MANAGEMENT AND EVENT CONTROL Categor API Remote Call Activate() Yes Terminate() No Chain() Yes Management Schedule() No GetID(Ref ) No GetStatus(, StateRef ) Yes SetEvent(, Event) Yes Event ClearEvent(Event) No Control GetEvent(, EventRef ) Yes WaitEvent(Event) No Caller Node FleRa Communication Callee Node call request transmission wait sstem call eecution Communication Ccle ccle start processing release return n th ccle n+1 th ccle n+2 th ccle return value transmission return processing Figure 11. Structure of Distributed Real- Operating Sstem Figure 12. Chart of Remote Sstem Call Simulink models to utilize DSM. However, mutual eclusion must be also considered even when the software modules are eecuted in a preemptive multi-task environment on a single processor sstem. A set of shared variables, not just a shared variable, can be handled as a distributed shared resource. For eample, a set of shared variables and in Figure 3 and Figure 4 can be handled as the same resource. The configuration of an application on OSEK OS is described in OIL (OSEK Implementation Language) [12]. For eample, tasks and events are staticall declared in an OIL file. The configuration data of OSEK OS are generated b the sstem generator (SG) referring to the OIL file. We etend OIL to declare distributed shared variables and distributed resources. III. DISTRIBUTED REAL-TIME OPERATING SYSTEM WITH DISTRIBUTED SHARED MEMORY A. Overview We have al developed a with locationtransparent sstem calls [7] as an etension to TOP- PERS/OSEK kernel, an OSEK-compliant operating sstem developed b TOPPERS project [13]. We etend the DR- TOS to support DSM based on the model presented in Section II-B. Figure 11 illustrates the structure of the, which consists of the OSEK OS original functions, a timer snchronization module, a remote sstem call module, a distributed shared memor module and configuration data. The timer snchronization module manages the global time. FleRa provides the network time that is snchronized between the FleRa controllers. The timer of the on each node is periodicall snchronized with the clock of the network time. The value of the timer of the is used as the global time. Table I shows the OSEK OS sstem calls for task management and event control. The column Remote Call of Table I shows whether the sstem call is etended to be a remote sstem call or not, i.e., Activate(), Chain(), GetStatus(), SetEvent() and GetEvent() are etended. Parameter means the task ID. In the etended sstem calls, a task ID is a unique ID in a distributed sstem, not onl unique in a node. If one of these sstem calls is issued specifing a remote task, the remote sstem call module eecutes the processing for the remote sstem call. Figure 12 shows a time chart of a remote sstem call. When an application task issues a remote sstem call, the remote sstem call module determines the node on which the target task resides, generates a request message, calls the FleRa driver to write the request message in the message RAM of the FleRa controller, and shifts the caller task to the waiting state. The communication of the request message is eecuted b FleRa controllers. Received request messages are stored in the message RAM of the FleRa controller of the callee node. The ccle start processing is eecuted b an ISR (Interrupt Service Routine), which is activated at the beginning of each FleRa communication ccle. The ccle start processing eecutes global time maintenance, calls the FleRa driver 252

6 to messages d in the previous communication ccle, interprets the request message, and calls the original sstem calls of OSEK OS. Then the ISR generates a return message and calls the FleRa driver to write the return message in the message RAM. The ISR of the caller node eecutes the ccle start processing, stores the return value and output parameters in a buffer, and releases the caller task from the waiting state. The caller task s the return value and output parameters from the buffer and resumes eecuting the application program. The distributed shared memor module manages the copies of shared variables and maintains the consistenc. The details of the DSM mechanism are described in Section III-B. The communication ccle of FleRa is divided into the static segment for periodic messages and the dnamic segment for event-triggered messages. The messages of remote sstem calls and DSM are transmitted in the dnamic segment because sstem calls and DSM accesses are eventuall performed. The configuration data consists of the original OSEK configuration data, task location data for remote sstem calls, and DSM configuration data. B. Distributed Memor Mechanism This section describes the details of the DSM mechanism of the. The copies of shared variables are allocated in the data section of application program on each node. The on each node has shared data buffers and d data buffers. We add DSM functionalities to and ReleaseResource() as described in Section II-C. We call the former DSM access preprocessing and the latter DSM access postprocessing. Figure 13 shows a time chart of the DSM processing on the writer node. When the application task calls before accessing to a shared variable, the eecutes the processing of the original of OSEK. Then, the determines if the resource is a DSM resource or not. If the resource is a DSM resource, the eecutes the DSM access preprocessing, which copies the value of the shared data buffer to the shared variable. When the application task calls ReleaseResource() after accessing to the shared variable, the determines if the resource is a DSM resource or not. If the resource is a DSM resource, the eecutes 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 FleRa driver to the former value if the values are different. Then the eecutes the processing of the original ReleaseResource() of OSEK OS. write ReleaseResource() 0 cop DSM buffer update DSM access DSM access cop preprocessing postprocessing Data Buffer interrupt FleRa Communication n th ccle n+1 th ccle Figure 13. DSM access postprocessing Data Buffer FleRa Communication n th ccle Figure 14. Chart of Writer Node Processing access inhibit interval write ReleaseResource() waiting DSM buffer update cop cop ccle start processing interrupt n+1 th ccle DSM access preprocessing Access Inhibit for Partiall-Sequential Consistenc ReleaseResource() ccle start cop processing DSM access DSM access Data preprocessing postprocessing Buffer d data update cop Received Data Buffer FleRa Communication n th ccle n+1 th ccle Figure 15. Chart of Reader Node Processing in Case 1 When the FleRa controller completes the data transfer, an interrupt occurs. The interrupt eecutes DSM buffer update, which copies the value of the shared variable to the shared data buffer. Figure 14 shows a time chart with an access inhibit interval. When the application task (er-writer task) calls until the FleRa controller completes the data transfer, the shifts the state of the task waiting. When the FleRa controller completes the data transfer, the interrupt checks if there is a task with state waiting or not. If such a task eists, the interrupt shifts the state of the task. This is implemented using the event mechanism of OSEK OS. Figure 15 shows a time chart of the DSM processing on the er node. The ccle start processing of the checks the data d during the previous communication ccle. If DSM data have been d, the eecutes 253

7 0 Data Buffer Received Data Buffer FleRa Communication n th ccle cop DSM access preprocessing ccle start processing d data update n+1 th ccle ReleaseResource() DSM access postprocessing cop Figure 16. Chart of Reader Node Processing in Case 2 d data update, which interprets the d data and checks if there is a task that holds the DSM resource. Figure 15 shows the case that no task holds the DSM resource. In this case, the d data update processing writes the d value into both the d data buffer and the shared data buffer. When the application task calls before accessing to a shared variable, the determines if the resource is a DSM resource or not. If the resource is a DSM resource, the eecutes DSM access preprocessing, which copies the value of the shared data buffer to the shared variable as described before. Then the application task s the value from the shared variable. Figure 16 shows a time chart in the case that there is a task that holds the DSM resource. In this case, the d data update processing writes the d value into just the d data buffer. When the application task calls ReleaseResource(), the eecutes the DSM access postprocessing, which copies the value of the d data buffer to the shared data buffer. C. Response of Distributed Memor FleRa communication parameters are staticall designed. Design and analsis methods for FleRa communication have been presented [14][15]. FleRa communication parameters must be designed considering frames for both the and the application program. The frames for the is determined b considering the maimum rate of DSM write operations and remote sstem calls performed in a communication ccle period. The maimum communication dela time is predictable if FleRa communication is well configured, and so the response time of a DSM service is predictable. In the eample time chart shown b Figure 13, the data transfer after the write operation is performed in the same communication ccle as the DSM access postprocessing is eecuted. However, the data transfer ma be postponed to the net communication ccle. 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 net to Writer write ReleaseResource() Node DSM access postprocessing FleRa Communication interrupt DSM buffer update Data Buffer ccle start processing Reader Node d data update n th ccle n+1 th ccle n+2 th ccle FleRa communication dela time Response of Distributed Memor Figure 17. DSM acess preprocessing Response of Distributed Share Memor the net communication ccle if the FleRa communication is well configured. The response time of the DSM service consists of the DSM access postprocessing eecution time, the FleRa communication dela time, the ccle start processing eecution time and the d data update eecution time. In the worst case, the maimum total time of the DSM access postprocessing eecution time and the FleRa communication dela time is twice the communication ccle period. So the worst case response time is the total of twice the communication ccle period, the ccle start processing eecution time and the d data update eecution time. It is about twice the communication ccle period because the ccle start processing eecution time and the d data update eecution time are sufficientl less than the communication ccle period. IV. IMPLEMENTATION AND EXPERIMENTAL EVALUATION We have developed a prototpe of the with the DSM mechanism described in Section III-B. The prototpe supports just the 32-bit data tpe for DSM. We manuall define the DSM configuration data because the current version of SG does not support DSM. We are now etending OIL and SG to automaticall generate the DSM configuration data. We have done eperiments to evaluate the performance of the prototpe. We use the evaluation boards called GT0N, the CPU of which is V850E/PH03 with an onchip E-Ra FleRa controller. The clock rate of the CPU is 128MHz. The data transfer rate of FleRa is MHz and the communication ccle period is 1msec. We have run an evaluation program and measured the CPU eecution times of DSM functions: the DSM access preprocessing eecution time, the DSM access postprocessing eecution time, the ccle start processing eecution time, the d data update eecution time, and the DSM buffer 254

8 Table II EXECUTION TIME OF DSM MECHANISM Processing Eecution [μsec] Average Worst DSM Access Preprocessing DSM Access with Data Transfer Postprocessing without Data Transfer Ccle Start Processing Received Data Update DSM Buffer Update Table III EXECUTION TIME OF RESOURCE ACCESS SYSTEM CALLS Eecution [μsec] Sstem Call TOPPERS/OSEK Kernel Average Worst Average Worst ReleaseResource() update eecution time. We have measured each eecution time fift times using a hardware counter, the clock rate of which is 32MHz. Table II shows their average values and the worst values. The values are in the case that the shared variable is a single 32-bit integer data. We think each eecution time is practicall small for automotive control sstems. The tpical period of the automotive control application periodic tasks is msec or more. The tpical event-triggered task of the automotive powertrain control sstem is a task snchronized with the crankshaft rotation, the period of which is msec when the speed of the crankshaft rotation is 6000rpm. The tpical FleRa communication ccle period is 1 msec. The dominant factor of the response time of the DSM is the FleRa communication dela time and the worst case response time is about twice the communication ccle. The worst case response time is about one fifth of the application task period in the tpical case, so we think the response time is practicall small. We have also measured the eecution time of and ReleaseResource() for a resource supported b original OSEK OS, not a distributed shared resource for DSM, to evaluate the overhead of the sstem calls. Table III shows their eecution time in the case of the and in the case of original TOPPERS/OSEK Kernel. The difference between them means the overhead caused b the DSM mechanism. We think the overheads are practicall small because their values are less than % of the eecution times of the sstem calls. V. CONCLUSIONS We have presented a that provides a DSM service for distributed embedded control sstems. The consistenc of the DSM is maintained according to the order of data transfer through FleRa, not using inter-node snchronization. The worst case response time of the DSM is predictable if the FleRa communication is well configured. We have developed a prototpe of the and evaluated the performance of the DSM. According to the evaluation results, we think the performance is practicall small for automotive control applications. We are now developing the net version of the with DSM that supports various data tpes of shared variables. We are also etending OIL and SG to automaticall generate the DSM configuration data. ACKNOWLEDGMENT We would like to thank the developers of TOP- PERS/OSEK Kernel. This work was supported in part b JSPS KAKENHI Grant Number REFERENCES [1] OSEK/VDX, Operating Sstem, Version 2.2.3, 05. [2] The MathWorks Inc., [3] A. Sangiovanni-Vincentelli and M. Di Natale, Embedded sstem design for automotive applications, IEEE Computer, Vol.40, No., pp.42 51, 07, doi:.19/mc [4] OSEK/VDX, Communication, Version 3.0.3, 04. [5] A. S. Tanenbaum, Dstributed Operating Sstems, Prentice Hall, New Jerse, [6] J. Protic, M. Tomasevic and V. Milutinovic, Distributed shared memor: concepts and sstems, IEEE Parallel & Distributed Technolog: Sstems & s, Vol.4, No.4, 1996, pp.63 71, doi:.19/ [7] T. Chiba, Y. Itami, M. Yoo and T. Yokoama, A Distributed Real- Operating Sstem with Location-Transparent Sstem Calls for Management and Inter-task Snchronization, Proc. IEEE th International Conference on Trust, Securit and Privac in Computing and Communications (Trust- Com), 11, pp , doi:.19/trustcom [8] R. Makowitz and C. Temple, FleRa - a communication network for automotive control sstems, Proc. 06 IEEE International Workshop on Factor Communication Sstems, pp.7 212, 06, doi:.19/wfcs [9] MathWorks Automotive Advisor Board (MAAB), Control Algorithm Modeling Guidelines Using MATLAB, Simulink, and Stateflow, Version 3.0, 12. [] S. V. Adve and K. Gharachorloo, memor consistenc models: a tutorial, IEEE Computer, Vol.29, No.12, 1996, pp.66 76, doi:.19/ [11] L. Lamport, How to make a multiprocessor computer that correctl eecutes multiprocess programs, IEEE Transactions on Computers, Vol.C-28, No.9, 1979, pp , doi:.19/tc [12] OSEK VDX, OSEK/VDX Sstem Generation OIL: OSEK Implementation Language Version 2.5, 04. [13] TOPPERS Project, [14] T. Pop, P. Pop, P. Eles, Z. Peng and A. Andrei, Timing analsis of the FleRa communication protocol, Proc. 18th Euromicro Conference on Real- Sstems, pp.3 216, 06, doi:.19/ecrts [15] J. Ben, B. Yongming and L. Anhu, A method for response time computation in FleRa communication sstem, Proc. IEEE International Conference on Intelligent Computing and Intelligent Sstems, Vol.3, pp.47 51, 09, doi:.19/icicisys