Logging Architecture#
Logging Architecture
|
status: draft
security: NO
safety: ASIL_B
|
||||
Overview#
The logging feature provides a standardized logging framework for C++ and Rust projects using Bazel build system.
Description#
The logging feature has two parts: the mw::log library that applications
link against and ship as part of their own binary, and the datarouter
daemon that runs as its own process. Applications never talk to datarouter
directly; mw::log’s remote backend writes log records into a shared-memory
segment and hands control over to datarouter through a shared-memory and
mw::com message-passing
session; guaranteeing Freedom from interference (FFI) for the application and its
logging subsystem. Rust applications reach that same remote backend too, via
the score_log_bridge described below, so datarouter sees one uniform
set of sessions regardless of which frontend produced them.
mw::log#
The mw::log library spans across two repositories:
score_baselibs/score/mw/log provides the Cpp frontend API, console backend, static recorder composition and
the score_log Rust facade that gives Rust code the same API surface, modelled on Rust’s own log crate.
This allows baselibs and mw::com
to log to the same backends as applications, and providing a common logging API for all
components. The library is linked into applications and shipped as part of their binary.
score_logging/score/mw/log provides concrete file, remote/DLT, and slog
recorders, plus the score_log_bridge that implements score_log
Log trait and forwards records over FFI into those same
recorders, so a Rust application ends up writing through the identical
remote backend.
Both repositories own their own safety plan, phase gates, and governance. The
cross-repository contract is the Recorder interface and static backend_table
registration. The existing C ABI seam is not used for static composition.
Runtime plugin loading remains experimental and is not a supported
production capability.
Datarouter#
The Datarouter is the Diagnostic log and trace (DLT) daemon. See the Datarouter component for its requirements and detailed design.
The diagram highlights the logging components and traces the
remote DLT path a log message takes once it leaves an application, including
a Rust application whose score_log_bridge registers as a recorder the same
way the C++ remote backend does and writes into its own shared-memory segment
for datarouter to read.
Design Constraint#
The logging function is not safety relevant (its output can not be used for safety functionality). But it must be usable also for safety related applications, hence the design shall guarantee Freedom From Interference (FFI).
Requirements#
The requirements for the feature architecture are defined in the requirements section of the feature documentation in the project repository.
Architecture Decomposition#
The feature is decomposed into a QM component which delivers the functionality and ASIL components providing the interface (divided into frontend and backend) which are included into the context of the using application. The frontend interface which is included by the users is deployed in the baselibs module. This is to avoid cycylic dependencies, as the other baselibs components want to use logging functions but also the logging components want to use baselibs functions.
Static Architecture#
Feature Architecture Logging
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Dynamic Architecture#
Simple routing of commands and replies, so dynamic view is not needed.
Logical Interfaces#
The logical interfaces of the feature are defined in the logical interfaces section of the feature documentation in the project repository.
See SCORE Features for more information.
Used Components#
The components used by the feature are defined in the components section of the module documentation.