Abstraction
Log 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 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 | UC.LS.1, UC.LS.2 | The logs shall be compressed when they are saved. | |
RQ.LS.4 | 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.5 | UC.LS.1,UC.LS.2 | The log-level of the log messages shall be configurable. | |
RQ.LS.6 | UC.LS.1,UC.LS.2 | The log messages shall be categorized according to the functionalities or domains. | |
RQ.LS.7 | UC.LS.1,UC.LS.2 | The System Logging Support module shall record the timestamp of the log messages. | |
| RQ.LS.8 | 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.9 | 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. 3, 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
2 Comments
Riku Nomoto
The memo that were pointed out at Virtual Workshop.
#
Item
where to store the log.
→ local only for this topic, but please freely add related usecases for now.
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.
Responsibility to analyze log. Log can't be lacking. Must keep complete log.
Keep it in local device
Bernard Craddock
Hi Riku,
For log and trace analysis we need to get the data off the vehicles (potentially millions of them) and back into the cloud do you have thoughts on how you're going to accomplish that?
If we take an analogy from cloud vendors they provide services that monitor and collect operational data in the form of logs, metrics and tracing into a unified view for remote developer and support analysis, of which considerable software components are open source from CNCF.
AWS already provide cloud offerings for most of this via containerized micro-service Orchestration, service integration, proxy configuration, Log routing etc.
It seems to me OEM's such as yourselves could save yourselves a lot of hard work and money utilizes these services without reinventing them, and I'm not suggesting they'd work out of the box as they'd probably need to be refactored for "In Vehicle - micro-services" but anyway is this something your company would consider.
copying in Haydn Peterswald Walt Miner and Scott Murray please correct me where I maybe mistaken - regards