-
New Feature
-
Resolution: Fixed
-
Major
-
None
-
QEMU x86_64
This section describes the software that is part of the Toyota product equivalent code. Toyota Code(called Base System) with the basic features of the system is located between OS layer and AGL Service layer
- URL(to upload codes)
https :// gerrit.automotivelinux.org/gerrit/staging/toyota.git
- Documents
https://confluence.automotivelinux.org/display/TC/Documents - How to build
https://confluence.automotivelinux.org/display/TC/Documents
- Use Cases(Typical)
| 1 | BackupManager | Necessity | Product System should keep data value before system shutdown because the user can use it in the same state. |
| UseCase | #1: “immediately” user change some data value and system should write this value as persistent data |
||
| UseCase | #2: “(When) System shutdown” At system shutdown, the system saves the system state and values. When the power is turned on again, the data storage process is interrupted and the system startup process is executed. In the startup process, the interrupted data storage process is executed. Therefore, the system startup process must be executed within a few seconds including data writing. |
||
| 2 | LoggerService | Necessity | In the product, it is necessary to record the operating conditions of application and the system. When malfunction occurred for software, it is necessary to analyze it promptly, and to make modifications. |
| UseCase | #1: Archive logs until system shutdown Logger-service collects the log that each service output and it compresses logs and saves compressed log. |
||
| UseCase | #2: Log archive when a system error is detected When the system detects a critical error even, Logger-service performs processing like #1. |
||
| 3 | SystemManager | Necessity | In the system, it is necessary to activate the optimal service in case of power condition changes or abnormalities. Because the power consumption is reduced. |
| UseCase | #1: System startup and shutdown Monitor the processing of each service according to the designed startup and shutdown sequence and manage the startup and shutdown processes of the system. |
||
| UseCase | #2: Behavioral branching of the system at the time of anomaly detection Appropriate processing in the event of abnormalities such as an external unit failure, abnormal termination of each service, or system memory exhaustion. |
||
| 4 | PowerService | Necessity | In this case, it exits for SystemManager. In the system, it is necessary to activate the optimal service in case of power condition changes or abnormalities. Because the power consumption is reduced. |
| UseCase | #1: Error detection and processing request notification Appropriate processing in the event of abnormalities such as an external unit failure, abnormal termination of each service, or system memory exhaustion. |
||
| 5 | ResourceManager | Necessity | The system monitors the CPU load and system memory usage, and performs fail-safe processing in the event of an abnormality. Because the system needs to maintain a state where it can provide services to users. |
| UseCase | #1: Monitor system memory | ||
| 6 | TaskManager | Necessity | The service needs to be started by a user or an external device. Because it is necessary to have a mechanism that can be started at any time for services that do not need to be started all the time. |
| UseCase | #1: Starting and terminating the service | ||
| 7 | Positioning | Necessity | In the IVI system, the location information is necessary for the navigation application to display the position of the car, and it is indispensable information for the in-vehicle system. |
| UseCase | #1: Get the latitude and longitude. | ||
| 8 | Communication | Necessity | In the IVI system, it is necessary to provide the display of vehicle information to the user by using the display of the IVI system. In this case, a communication method such as CAN is required to obtain information from the ECU. |
| UseCase | #1: Sending and receiving CAN data | ||
| * | will add use cases |