Abstraction
Log and diagnostics information are 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 module are described.
Table 1
| # | Item | User |
|---|---|---|
UC.LS.1 | Check 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
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
