Abstraction
This chapter provides requirements for the function of the System Logging Support.
In the use of IVI products, it is necessary to collect and centrally manage logs created in multiple places in the system, which are records of various events and times that occurred in systems. The reasons to keep logs are for security measures or information gathering and decision making in the operation, management and countermeasure for anomalies of the product systemLog and diagnostics information is very important to check the system health condition and analyze potential and already observed issues. As a way of logging, printf() style easy approach to put logging messages can be convenient for developers, however the console is usually not available. Therefore, how and where to save the log need to be considered.
Depending on the use cases to output, collect and analyze log information, it is necessary to prioritize the log-levels. Critical error information must be recorded and shall not be overwritten by the limited log storage on the IVI system. Information such as service or messages may be useful for developers to analyze problems.
This chapter describes the use cases with System Logging Support(the function of logging as described above), the functional requirements for realizing the use cases, and the functions of the Basesystem that can be used as a sample implementation.
Use case
In the following table, use cases which need System Logging Support function module are described.
As use cases, two cases need to be assumed: before and after product shipment.
Table 1
| # | Item | User |
|---|---|---|
UC.LS.1 | Developers check the logs for implementation and evaluation to debug. | OEM/Developer(Before product shipment) |
| 2 | From a security perspective, OEM examines the logs to investigate whether there has been unauthorized access to the system from outside. | OEM/Developer(After product shipment) |
| 3 | When some anomaly in the system requires a measure to a product failure, OEM investigates the cause of the problem. | OEM/Developer(After product shipment) |
#1 : Before product shipment
#2, 3 : After product shipment
Discussion Space for additional use cases(Freely write please) ~17:35
# | Item |
|---|---|
| 1 | where to store the log. → local only for this topic, but please freely add related usecases for now. |
| 2 | Dynamic monitoring of IVI system, for Cyber security, ex. audit, intrusion detection? This case has something in common with #2 in the use case section above, so add the necessary parts to #2. |
| 3 | Responsibility to analyze log. Log can't be lacking. Must keep complete log. Keep it in local device |
Functional Requirements
This table includes the functional requirements of System Logging support module.
| # | Item | ||
|---|---|---|---|
1 | Use case #1, 2 | When ACC-OFF, log from system startup to shutdown should be saved in the defined directory. | |
2 | Use case #1, 3 | When system anomaly is detected, error detection log should be kept. | |
3 | Use case #1, 2, 3 | Where to store logs should be defined. | |
4 | Use case #1, 2, 3 | Considering the endurance, the log should be recorded in the volatile memory and recorded in the non-volatile memory as necessaryCheck logs during development | The developers (OEM/Supplier) check and evaluate the logs by each function (application) when implementing the product software. |
UC.LS.2 | Check logs of already used products | In order to investigate the status and problems of used products, OEM analyze the stored logs by each function (application). |
Functional Requirements
This table shows the functional requirements of System Logging Support module.
Table 2
| # | Item | Related Use Case | Description |
|---|---|---|---|
RQ.LS.1 | Log save | UC.LS.2 | The System Logging Support module shall preserve any recorded log messages even through system startup/shutdown lifecycle. |
RQ.LS.2 | UC.LS.1,UC.LS.2 | The storage of logs shall be able to be configurable(e.g. The log storage device or directory). | |
RQ.LS.3 | The setting of log messages | UC.LS.1,UC.LS.2 | Log messages should have several levels depending on their importance. For example, the following.
|
RQ.LS.4 | UC.LS.1,UC.LS.2 | The log-level of the log messages shall be configurable. | |
RQ.LS.5 | UC.LS.1,UC.LS.2 | The log messages shall be categorized according to the functionalities or domains. | |
RQ.LS.6 | UC.LS.1,UC.LS.2 | The System Logging Support module shall record the timestamp of the log messages. | |
RQ.LS.7 | UC.LS.1,UC.LS.2 | The System Logging Support module shall not overwrite any critical log information, e.g. information on possible reasons to restart the system, even though the system log storage is full. | |
RQ.LS.8 | Storage memory | UC.LS.1,UC.LS.2 | The System Logging Support module shall minimize actual write operations to the storage device to make the lifetime as long as possible. |
System Logging Support in Basesystem
Reference implementation in Basesystem
The following functions are related to the System Logging Support function in Basesystem.
- Logger service
Logger Service
Logger service is the unit to collect the log, save in a non-volatile area (USB/SD). When receiving the storing request, Logger service reads the log generated by other modules and saves it.
Reference code
Logger service
In the implementation of Basesystem, the function module for System Logging Support is partially covered by Logger Service and Framework Unified.
Logger Service does not create logs by itself, but rather collects and archives the logs left by other modules when there is a request to save them in the system. As shown in Fig. 24, for example, when the ACC is turned off(ⅰ), the system manager notifies the Logger Service of this information, and the Logger Service collects the logs from other modules covering the period from system startup to shutdown, and stores them in the storage. When an failure occurs in the system(ⅱ), it is another trigger for logging, and the Logger Service stores the log by receiving the request. The logs are stored in the volatile area on a regular basis, but when the capacity becomes full, they are stored in the non-volatile area. Framework Unified is responsible for outputting the logs. Upon request from the required service, a log level is specified and the log is output to a buffer. Logging levels include typical definitions such as Info, Warning, and Error, and additional levels can be set optionally by the user. These functions are the role of System Logging Support.
Figure 3
