Abbreviation
- Adaptive Applications (AA)
- AUTOSAR Runtime for Adaptive applications (ARA)
- Execution Management (EM)
- Communication Management (CM)
- Operating System (OS)
- Inter-Process-Communication (IPC)
- Operating System Interface (OSI)
Concepts:
- Language bindings are wrapper libraries that bridge two programming languages, so that a library written for one language can be used in another language
- PSE51 (a single-process profile) is a subset of POSIX created for the purpose of embedded real-time systems. A description can be found in IEEE 1003.13-2003.
- The AUTOSAR adaptive platform is not going to become like Linux, but Linux (or other POSIX-compliant OS) can be taken to host an AUTOSAR adaptive platform.
Adaptive Platform defines an execution context and OSI (contains standard application interface) for use by AAs.
AA run on top ARA
=> ARA consists of application interfaces provided by Functional Clusters
=> Functional Clusters belong to Adaptive Platform Foundation
=> Adaptive Platform Foundation = fundamental functionalities + platform standard services (Adaptive Platform Services)
AA can provide Services (Non-platform service) to other AA
=> AA and Functional Clusters may use non-standard interfaces, but ensure not conflict with the standard AP functionalities and portability onto other AP implementations
ARA implementation ???
- The language binding is based on C++
- The C++ Standard library
- Only PSE51 interface (OS API)
Life-cycles of AA ???
=> Application launch and shutdown
- Managed by EM (Loading/launching an AA)
=> all the Functional Clusters are applications from EM point of view
- To launch an AA needs configuration at system integration time or at runtime
Interaction between AAs ???
- Service requests/replies
=> uses CM for both intra-machine and inter-machine and transparent to applications.
Interaction between Functional Clusters and AAs ???
- uses IPC under "Library-based" design or "Service-based" design
+ "Library-based" calls IPC directly
=> Uses "Library-based" locally in an AP instance
+ "Service-based" uses CM functionality (AA <=> Cm or AA <=> Server proxy <=> CM)
=> Uses "Service-based" for other AP instance (distributed fashion)
Interaction between Functional Clusters ???
- use "public" ARA interfaces of other Functional Clusters
- use "protected" interfaces of Functional Clusters to provide privileged access
AP Operating System point of view ???
=> required to provide multi-process POSIX OS capability
=> the AP and AA are just a set of processes
=> Each AA is implemented as an independent process
=> Functional Clusters are implemented as processes
=> These processes interact with each other through IPC or OS functionalities
=> The Adaptive Platform Services and the non-platform Services are also implemented as processes
=> These processes can have single-threaded or multi-threaded
=> If AAs running on top of ARA, they should only use PSE51.
=> If more features are needed they will be taken from the POSIX standard
=> If a process is the Functional Clusters, it can use available OS API or further POSIX calls
=> The use of specific calls will be left open to the implementer and not standardized.
=> the OS provide interfaces, such as creating processes, that are required by Execution Management to start an Application
=> They are platform implementation dependent (not belong to ARA)
=> OSI provides both C and C++ interfaces.
=> C program includes C function calls defined in the POSIX standard, namely PSE51 defined in IEEE1003.13 [1]
=> C++ program includes function calls defined in the C++ Standard and its Standard C++ Library
Scheduling ???
- Use standard scheduling policies of POSIX standard : SCHED_FIFO and SCHED_RR
- Other scheduling policies are allowed, but check portablity across different AP implementations
AP runs on as a Machine/hardware ???
=> a hardware can be one or more Machines and a single instance of AP runs on a machine
=> hardware may be virtualized using Hypervisor
Memory management ???
Ref: https://stackoverflow.com/questions/12488010/why-the-entry-point-address-in-my-executable-is-0x8048330-0x330-being-offset-of
- The process’s address space is virtualized.
- Each process has its own address space (the addresses where code and data are located may or may not correspond to their underlying physical storage address)
Execution Management ???
- Working in cooperation with OS
=> responsible for platform initialization and the start-up/shut-down of Applications
=> run-time scheduling of AAs
- Initialization process : OS first -> Execution Management -> Platform-level Applications -> AAs
- The startup order of the Platform-level Applications and the AAs are based on Machine Manifest and Application Manifest information
- Depending on the Machine State, deployed AAs are started during Platform-level Applications startup or later
Machine State Management ???
- Machine State Management define the state of the operation for an Adaptive Platform.
- The Application Manifest allows definition in which Machine State the Application Executables shall run
- Grants full control over the set of Applications to be executed
- Composed of mandatory and non-standardized machine states
- Machine State Management can be integrated directly in the EM or as a separate Machine State Management Application.
Communication Management ???
=> how a defined service is presented to the application implementer (upper layer, Language Binding) as well as the respective representation of the service’s data on the network (lower layer, Network Binding).
- Service Oriented Communication (intra-machine communication and inter-machine communication)
+ A service consists of : Events, Methods, Fields
+ Need a Service Registry acts as a brokering instance (services registers, services querying-Service Discovery)
Figure: Service Oriented Communication
- Language binding and Network binding
+ Language binding : the methods, events and fields of a service are translated into directly accessible identifiers of the targeted programming language
+ The Network Binding : data of a configured service is serialized and bound to a specific network
+ Service Registry is also part of the Network Binding
+ The interface between Language Binding and Network Binding is private interface inside Communication Management software
=> Generated Proxies and Skeletons of C++ Language Binding ???
- The upper layer interface of the C++ Language Binding provides an object-oriented mapping of the services
- A generator that is part of the development tooling for the Communication Management software generates C++ classes
+ On the service implementation side these generated classes are named Service Provider Skeletons.
+ On the client side, these generated classes are called Service Requester Proxies.
- Service Requester Proxy provides mechanisms for synchronous (blocking the caller until the server returns a result) and asynchronous calling (called function returns immediately).
- Proxy classes can be used directly by the client
- The Service Provider Skeletons are abstract classes. A service implementation shall derive from the generated base class and implement the respective functionality.
=> Communication paths configuration ???
- Only Full service discovery in the application is available in Release 17-03: No communication paths are known at configuration time. An API for Service discovery allows the application code to choose the service instance at runtime.
Diagnostics ???
- The Diagnostic Management realizes the ISO 14229-5 (UDSonIP) which is mainly based on the ISO 14229-1 (UDS) and ISO 13400-2 (DoIP).
Persistency ???
=> Offers a library based approach to access the non-volatile memory for Applications to store data over boot and ignition cycles.
- Fulfill the PSE51 requirements not to create or delete files during runtime
- Currently the used storage location identifiers are simply file names
=> 2 categories of storage locations: Key-Value Storage and Stream Storage
- Key-Value Storage : store and retrieve multiple Key-Value pairs in one storage location.
+ The supported value types are base types, PODs (C++ Plain Old Data structures) and arrays/containers derived from these types, AUTOSAR data types
- Stream Storage : raw access to file like structures
Safety ???
- protect the exchange of information inside the vehicle and with the external world including fault detection if any corruption has occurred but no mechanisms to guarantee the integrity of data (e.g: E2E-Protection)
- monitor the correct execution of platform functionalities and AAs
- safe and secure usage of programming languages
- Watchdog functionality : Alive supervision, Deadline supervision, Logical supervision, Error handling of supervision errors
- Adaptive Applications (AA)
- AUTOSAR Runtime for Adaptive applications (ARA)
- Execution Management (EM)
- Communication Management (CM)
- Operating System (OS)
- Inter-Process-Communication (IPC)
- Operating System Interface (OSI)
Concepts:
- Language bindings are wrapper libraries that bridge two programming languages, so that a library written for one language can be used in another language
- PSE51 (a single-process profile) is a subset of POSIX created for the purpose of embedded real-time systems. A description can be found in IEEE 1003.13-2003.
- The AUTOSAR adaptive platform is not going to become like Linux, but Linux (or other POSIX-compliant OS) can be taken to host an AUTOSAR adaptive platform.
Adaptive Platform defines an execution context and OSI (contains standard application interface) for use by AAs.
Figure: AP platform
AA run on top ARA
=> ARA consists of application interfaces provided by Functional Clusters
=> Functional Clusters belong to Adaptive Platform Foundation
=> Adaptive Platform Foundation = fundamental functionalities + platform standard services (Adaptive Platform Services)
AA can provide Services (Non-platform service) to other AA
=> AA and Functional Clusters may use non-standard interfaces, but ensure not conflict with the standard AP functionalities and portability onto other AP implementations
ARA implementation ???
- The language binding is based on C++
- The C++ Standard library
- Only PSE51 interface (OS API)
Life-cycles of AA ???
=> Application launch and shutdown
- Managed by EM (Loading/launching an AA)
=> all the Functional Clusters are applications from EM point of view
- To launch an AA needs configuration at system integration time or at runtime
Interaction between AAs ???
- Service requests/replies
=> uses CM for both intra-machine and inter-machine and transparent to applications.
Interaction between Functional Clusters and AAs ???
- uses IPC under "Library-based" design or "Service-based" design
+ "Library-based" calls IPC directly
=> Uses "Library-based" locally in an AP instance
+ "Service-based" uses CM functionality (AA <=> Cm or AA <=> Server proxy <=> CM)
=> Uses "Service-based" for other AP instance (distributed fashion)
Interaction between Functional Clusters ???
- use "public" ARA interfaces of other Functional Clusters
- use "protected" interfaces of Functional Clusters to provide privileged access
AP Operating System point of view ???
=> required to provide multi-process POSIX OS capability
=> the AP and AA are just a set of processes
=> Each AA is implemented as an independent process
=> Functional Clusters are implemented as processes
=> These processes interact with each other through IPC or OS functionalities
=> The Adaptive Platform Services and the non-platform Services are also implemented as processes
=> These processes can have single-threaded or multi-threaded
=> If AAs running on top of ARA, they should only use PSE51.
=> If more features are needed they will be taken from the POSIX standard
=> If a process is the Functional Clusters, it can use available OS API or further POSIX calls
=> The use of specific calls will be left open to the implementer and not standardized.
=> the OS provide interfaces, such as creating processes, that are required by Execution Management to start an Application
=> They are platform implementation dependent (not belong to ARA)
=> OSI provides both C and C++ interfaces.
=> C program includes C function calls defined in the POSIX standard, namely PSE51 defined in IEEE1003.13 [1]
=> C++ program includes function calls defined in the C++ Standard and its Standard C++ Library
Scheduling ???
- Use standard scheduling policies of POSIX standard : SCHED_FIFO and SCHED_RR
- Other scheduling policies are allowed, but check portablity across different AP implementations
AP runs on as a Machine/hardware ???
=> a hardware can be one or more Machines and a single instance of AP runs on a machine
=> hardware may be virtualized using Hypervisor
Memory management ???
Ref: https://stackoverflow.com/questions/12488010/why-the-entry-point-address-in-my-executable-is-0x8048330-0x330-being-offset-of
- The process’s address space is virtualized.
- Each process has its own address space (the addresses where code and data are located may or may not correspond to their underlying physical storage address)
Execution Management ???
- Working in cooperation with OS
=> responsible for platform initialization and the start-up/shut-down of Applications
=> run-time scheduling of AAs
- Initialization process : OS first -> Execution Management -> Platform-level Applications -> AAs
- The startup order of the Platform-level Applications and the AAs are based on Machine Manifest and Application Manifest information
- Depending on the Machine State, deployed AAs are started during Platform-level Applications startup or later
Figure: AP start-up process
Machine State Management ???
- Machine State Management define the state of the operation for an Adaptive Platform.
- The Application Manifest allows definition in which Machine State the Application Executables shall run
- Grants full control over the set of Applications to be executed
- Composed of mandatory and non-standardized machine states
- Machine State Management can be integrated directly in the EM or as a separate Machine State Management Application.
Communication Management ???
=> how a defined service is presented to the application implementer (upper layer, Language Binding) as well as the respective representation of the service’s data on the network (lower layer, Network Binding).
- Service Oriented Communication (intra-machine communication and inter-machine communication)
+ A service consists of : Events, Methods, Fields
+ Need a Service Registry acts as a brokering instance (services registers, services querying-Service Discovery)
- Language binding and Network binding
+ Language binding : the methods, events and fields of a service are translated into directly accessible identifiers of the targeted programming language
+ The Network Binding : data of a configured service is serialized and bound to a specific network
+ Service Registry is also part of the Network Binding
+ The interface between Language Binding and Network Binding is private interface inside Communication Management software
=> Generated Proxies and Skeletons of C++ Language Binding ???
- The upper layer interface of the C++ Language Binding provides an object-oriented mapping of the services
- A generator that is part of the development tooling for the Communication Management software generates C++ classes
+ On the service implementation side these generated classes are named Service Provider Skeletons.
+ On the client side, these generated classes are called Service Requester Proxies.
- Service Requester Proxy provides mechanisms for synchronous (blocking the caller until the server returns a result) and asynchronous calling (called function returns immediately).
- Proxy classes can be used directly by the client
- The Service Provider Skeletons are abstract classes. A service implementation shall derive from the generated base class and implement the respective functionality.
=> Communication paths configuration ???
- Only Full service discovery in the application is available in Release 17-03: No communication paths are known at configuration time. An API for Service discovery allows the application code to choose the service instance at runtime.
Figure: Language binding and Network binding
Diagnostics ???
- The Diagnostic Management realizes the ISO 14229-5 (UDSonIP) which is mainly based on the ISO 14229-1 (UDS) and ISO 13400-2 (DoIP).
Persistency ???
=> Offers a library based approach to access the non-volatile memory for Applications to store data over boot and ignition cycles.
- Fulfill the PSE51 requirements not to create or delete files during runtime
- Currently the used storage location identifiers are simply file names
=> 2 categories of storage locations: Key-Value Storage and Stream Storage
- Key-Value Storage : store and retrieve multiple Key-Value pairs in one storage location.
+ The supported value types are base types, PODs (C++ Plain Old Data structures) and arrays/containers derived from these types, AUTOSAR data types
- Stream Storage : raw access to file like structures
Safety ???
- protect the exchange of information inside the vehicle and with the external world including fault detection if any corruption has occurred but no mechanisms to guarantee the integrity of data (e.g: E2E-Protection)
- monitor the correct execution of platform functionalities and AAs
- safe and secure usage of programming languages
- Watchdog functionality : Alive supervision, Deadline supervision, Logical supervision, Error handling of supervision errors
0 nhận xét:
Đăng nhận xét