Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

More documents

Recommendations

Info

Chapter 2 AUTOSAR DataReceivePoint It describes an access to a client port and a concrete data element of that port. The value, which is returned, is the current value. DataWriteAccess It describes an implicit access to a sender port and a concrete data element of that port. The runnable can access the port multiple times, but just the last written value will be available at the port after termination of the runnable. DataReadAccess It describes an implicit access to a receiver port and a concrete data element of that port. The runnable can access the port multiple times during one execution and will get the same value every time. AsynchronousServerCallPoint A runnable calls a server with an asynchronous call through a client port. It has to be specified, which client port and which provided operation is used. An asynchronous call returns directly for the invoking runnable. The result is not available by now, instead it has to be fetched later by another call when the operation is finished. SynchronousServerCallPoint A runnable calls a server with an synchronous call through a client port. It has to be specified, which client port and which provided operation is used. A synchronous call returns not until the operation is finished and the result is available. WaitPoint A special item in this enumeration is the WaitPoint. All other items refers to a port and a special data element or operation of the port. Instead of that a WaitPoint refers an RTE event for which can be waited. The call does not return until the event or a specified timeout occurs. It can be seen in this enumeration, that the accesses are described in very detail. So e.g. a runnable can read a data element of a port directly and another data element of the same port with an implicit access. RTE Events For the RTE some events can be specified. An event can either trigger a runnable or wake up a WaitPoint. The following events are defined by AUTOSAR. TimingEvent For this event an interval and an offset has to be specified. So the points in time are given at which the event occurs. DataReceivedEvent This event is specified for a receiver port and for a concrete data element of the port. It occurs when new data is received. DataReceivedErrorEvent This event is also specified for a receiver port and for a concrete data element of the port. But it occurs when data is invalidated for a communication. DataSendCompletedEvent The DataSendCompletedEvent have to be specified for a sender port and a DataSendPoint. It occurs when the sending of a data element is completed. 12
2.4 Basic Concepts OperationInvokedEvent This event is called when an operation for a server port is invoked. The event is specified with the port and with the operation for which it should occur. AsynchronousServerCallReturnsEvent If an asynchronous call is used to invoke an operation on a server, the result of the server call can be fetched at later time. This event shows, that the server is finished and the result is available. It is specified for a client port and an operation, which is called by the client. ModeSwitchEvent For this event a mode and an action “entry” or “exit” has to be specified. The event arises when the specified mode is entered or exited, depending on which action is specified. Every event can trigger a runnable, but not every event can wake up a WaitPoint. The events, which can wake up a WaitPoint, are DataReceivedEvents, DataSendCompletedEvents and AsynchronousServerCallReturnsEvents. Inter Runnable Variable Ports define the interaction between SWCs, or more precise the interaction between the runnables of the SWCs. For runnables of one SWC another mechanism for internal communication exists. These are the Inter Runnable Variables (IRVs), which can be accessed by the runnables. Runnables could also use global variables for this internal communication, but with IRVs protection mechanism are provided by the RTE for concurrency. Exclusive Area Exclusive Area are a similar mechanism to the operating system resources described in section 2.3.3. Exclusive areas just provide mutual exclusive access for the runnables of one SWC, but not for the whole task. Exclusive areas can be implemented with operating system resources, but this is no requirement. There can be other implementation possibilities specified like e.g. interrupt–disabling. 2.4.5 Modes Modes have the simple purpose that components can provide a different behavior depending on which mode is active. The mode can be distributed from a component through ports to other components. Typical modes for a motor control unit are “Start”, “Drive” and “Stop”. A mode has to be distributed through a port, because there must be the possibility to provide modes to other ECUs. RTE Events can be disabled in a mode. Then the event is prevented, if a special mode is active. This makes it possible to execute runnables just in one mode. A ModeSwitchEvent responds directly to a mode switch. It triggers a runnable if a special mode is entered or left. These runnables can be used to clean up the old mode or prepare the new mode. 13
Page 1: Evaluation Environment for AUTOSAR-
Page 5: Danksagung An dieser Stelle möchte
Page 8 and 9: Contents 4 Goals 29 4.1 Background
Page 10 and 11: Contents Abbreviations 105 Bibliogr
Page 12 and 13: Chapter 1 Introduction not allow to
Page 14 and 15: Chapter 2 AUTOSAR 2.1 Architecture
Page 16 and 17: Chapter 2 AUTOSAR the hardware depe
Page 18 and 19: Chapter 2 AUTOSAR Basic task Basic
Page 20 and 21: Chapter 2 AUTOSAR communications. T
Page 24 and 25: Chapter 2 AUTOSAR mode A mode depen
Page 26 and 27: Chapter 2 AUTOSAR not absolutely tr
Page 28 and 29: Chapter 2 AUTOSAR 1 types Int
Page 30 and 31: Chapter 2 AUTOSAR 1 swc root
Page 32 and 33: Chapter 2 AUTOSAR 1 TASK(Task1) { R
Page 34 and 35: Chapter 2 AUTOSAR 24
Page 36 and 37: Chapter 3 MEDC17 3.2 Basic Software
Page 38 and 39: Chapter 3 MEDC17 28
Page 40 and 41: Chapter 4 Goals Communication The c
Page 42 and 43: Chapter 4 Goals 4.1.3 Development o
Page 44 and 45: Chapter 4 Goals files for special p
Page 46 and 47: Chapter 5 Analysis and Design test
Page 48 and 49: Chapter 5 Analysis and Design 38 na
Page 50 and 51: Chapter 5 Analysis and Design confi
Page 52 and 53: Chapter 5 Analysis and Design group
Page 54 and 55: Chapter 5 Analysis and Design direc
Page 56 and 57: Chapter 5 Analysis and Design The s
Page 58 and 59: Chapter 5 Analysis and Design 48
Page 60 and 61: Chapter 6 Implementation of the Tes
Page 72 and 73:
Chapter 6 Implementation of the Tes
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Chapter 7 Test Cases These examples
Page 88 and 89:
Chapter 7 Test Cases • The AUTOSA
Page 90 and 91:
Chapter 7 Test Cases SWC1 run11 SWC
Page 92 and 93:
Chapter 7 Test Cases 1 #include #i
Page 94 and 95:
Chapter 7 Test Cases 1 #ifndef TEST
Page 96 and 97:
Chapter 7 Test Cases 7.3.2 Implemen
Page 98 and 99:
Chapter 7 Test Cases 1 FUNC(void, R
Page 100 and 101:
Chapter 7 Test Cases 7.9. The sourc
Page 102 and 103:
Chapter 8 Conclusion Since a templa
Page 104 and 105:
Appendix A Example /interfaces/CS
Page 106 and 107:
Appendix A Example /interfaces/SR
Page 108 and 109:
Appendix A Example 98
Page 110 and 111:
Appendix B Requirements of the Func
Page 112 and 113:
Page 114 and 115:
Page 117 and 118:
Bibliography [1] FlexRay Protocol S
show all

Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

Create successful ePaper yourself

Delete template?

Save as template?