mw::log Component Requirements#

Logging Component Requirements
status: valid
security: YES
safety: ASIL_B

Log and Trace#

Log and Trace Framework consists of logging libraries and datarouter. The applications use logging libraries to write logs. datarouter implements logging daemon functionality, and can forward log messages from applications as DLT messages.

Use Log and Trace Framework
status: valid
security: NO
safety: QM

All output from logging and instrumentation based logging shall go through “mw::log” framework.

mw::log Configuration#

Logging libraries use static configuration based on .json files.

Uniform Configuration File
status: valid
security: NO
safety: QM

mw::log shall be uniformly configured via an application-specific configuration file. Configuration file location shall be relative to application binary. E.g.: ./<application name>/etc/logging.json.

Log Configuration Parameters
status: valid
security: NO
safety: QM

Application log configuration shall provide information necessary for log message generation and filtering. The provided parameter set includes, but is not limited to the following: application ID (appId), log mode for mw::log, default log level, log level assignments for individual context IDs.

Global Configuration Basis
status: valid
security: NO
safety: QM
reqtype: Functional

Global configuration shall be used as basis for all applications. Global configuration shall remain in the file /etc/ecu_logging_config.json. Application-specific configuration shall override the global defaults.

Configuration Fallback Defaults
status: valid
security: NO
safety: QM
reqtype: Functional

mw::log shall fall back to a default value for a configuration item that is not available from the configuration files.

Discard Syntax Error Configuration
status: valid
security: NO
safety: QM
reqtype: Functional

mw::log shall discard configuration files with syntax errors.

Discard Missing Configuration Files
status: valid
security: NO
safety: QM
reqtype: Functional

mw::log shall discard configuration files that are not found.

Discard Invalid Settings
status: valid
security: NO
safety: QM
reqtype: Functional

mw::log shall discard invalid configuration settings.

mw::log#

Avoid Signal Processing
status: valid
security: YES
safety: ASIL_B

The component shall not register any signal handler.

File Descriptor Flags
status: valid
security: YES
safety: ASIL_B
reqtype: Functional

The component shall set the FD_CLOEXEC (or O_CLOEXEC) flag on all the file descriptors it owns.

Note: This requirement can be satisfied in unit-test, by checking int flags = fcntl(fd, F_GETFD); assert((flags != -1) && (flags & FD_CLOEXEC)); for every file descriptor owned by the component.

DLT Verbose Mode
status: valid
security: NO
safety: QM
reqtype: Functional

mw::log shall implement DLT verbose mode. Generation of messages shall be done in DLT-conform format, allowing messages to be sent by Datarouter without additional reprocessing.

AUTOSAR Log and Trace Specification
status: valid
security: YES
safety: QM

mw::log shall implement “Specification of Log and Trace for Adaptive Platform”. Release of specification used shall be in agreement with the rest of Adaptive AUTOSAR stack.

Send Messages to Datarouter
status: valid
security: NO
safety: QM

mw::log shall use logging library to send verbose messages to datarouter. Applications shall use mw::log interface to log verbose mode messages. Internally mw::log shall be using logging library.

Inactive LogStream Behavior
status: valid
security: NO
safety: QM

mw::log library shall not perform any useful activity if log level of LogStream object is insufficient for given context. LogStream object shall not generate serialized messages if the severity of the message does not allow it to be sent.

Shared Memory File Permissions
status: valid
security: YES
safety: ASIL_B

Logging shared-memory files shall have read-only posix file permission for group and others. The shared-memory file created by mw::log shall be read-only for group and others.

Note: mw::log creates a shared memory file for each app.

System Backend#

System logger backend shall forward the logs to the native system logger.

Forward to System Logger
status: valid
security: NO
safety: QM
reqtype: Functional

The system logger backend shall forward the logs to the native system logger mechanism.

Note: Under QNX, slogger2 shall be used.

System Backend Activation
status: valid
security: NO
safety: QM
reqtype: Functional

The system logger backend shall be enabled if and only if the log mode contains “kSystem”.

Non-Functional Requirements#

Local Allocation Strategy
status: valid
security: YES
safety: ASIL_B

mw::log shall use local allocators to avoid using global heap. Global heap allocation (if any) shall be limited to initialization phase of application lifecycle.

No Endless Loops
status: valid
security: YES
safety: ASIL_B

mw::log shall not contain unbound loops or loops with unchecked exit conditions.

Avoid Locks
status: valid
security: YES
safety: ASIL_B

mw::log shall be free of time-unbound locks and shall implement strategies to limit wait time. Time limit shall be defined based on requirements from functions on individual ECU. Mutual exclusion mechanisms shall include priority inversion protection.

Cross-Locking Prevention
status: valid
security: YES
safety: ASIL_B

Cross-application and cross-thread dependencies shall be avoided. A thread logging in a loop shall not block other thread’s execution.

Index and Size Checking
status: valid
security: YES
safety: ASIL_B
reqtype: Non-Functional

Indices in data structures and sizes of data accessed or copied shall be checked for plausibility to avoid high runtime utilization through long iterations or data corruption.

Memory Bound Checking
status: valid
security: YES
safety: ASIL_B
reqtype: Non-Functional

Memory boundaries shall be explicitly checked when writing to shared memory.