initial version of logging feature request #206
Conversation
30e0936 to
3d6a578
Compare
|
We will try to bring our comments #68 (comment) here.. |
| Logging has to support the following features: | ||
| - Timestamping | ||
| - Log/serverity levels | ||
| - Log priorisation in case of ressource conflicts |
There was a problem hiding this comment.
Let us detail out what the actual use case is. When will prioritization be needed. What kind of resource conflicts are considered.
| Log Sources | ||
| ----------- | ||
|
|
||
| - raw sensor data e.g. video streams |
There was a problem hiding this comment.
With something as large as a video stream - is this really logging, or rather data recording? 🤔
There was a problem hiding this comment.
E.g. how does this match line 86:
Logs shall appear on stdout when running unit tests
I rather agree with a definition of logging as small status messages from running applications, which can be shown on stdout or sent to another sink. But raw sensor data sounds rather like data recording to me than logging.
There was a problem hiding this comment.
In my opinion "- raw sensor data e.g. video streams" belongs to replay.
source https://eclipse-score.github.io/score/requirements/stakeholder/index.html#STKH_REQ__290
STKH correction needed
There was a problem hiding this comment.
STKH will be corrected (split in two)
| - Runtime ressources | ||
| - Low impact on overall performance ---> QoS for handling overflows/dropping log messages |
There was a problem hiding this comment.
Ideally, in a language like Rust, logging messages should be possible without allocations for individual logs.
Using the defacto standard log crate as facade, implementors of this facade should not allocate to write / forward log messages.
There was a problem hiding this comment.
Design decision for detailed design => copy there
| ------- | ||
|
|
||
| - Supported operating system: QNX, Linux (encapsulation via OSAL) | ||
| - Supported programming languages: C++, Rust, Python (e.g. for tests) |
There was a problem hiding this comment.
For Rust, we would like to be able to use the log crate. It provides an (allocation-free) facade without forcing a specific logger implementation. Advantages of using this facade:
- We stay with language best-practices.
- New contributors directly feel at home with the logging.
- Any library dependency which we might use probably logs against this facade. So we would get logs of dependencies for free by using it as well and implementing a logger for the facade.
There might be comparable defacto standards for C++ and Python.
There was a problem hiding this comment.
Design decision for detailed design => copy there
There was a problem hiding this comment.
Python comes with logging out of the box and the concepts are similar to Rust, where you can add custom 'handlers'.
C++ doesn't really have such a standardized interface. There are libraries like log4cplus or spdlog or even boost logging which are all more or less common. But nothing as standardized as with the other two.
|
Thank you for the suggestion @arsibo ! In general, I can recommend this typo checked which works incredibly fast even on large codebases (and also typo-checks variable names etc.): https://github.com/crate-ci/typos?tab=readme-ov-file#typos |
|
|
||
| Norms/Standards | ||
| --------------- | ||
|
|
There was a problem hiding this comment.
- Standardized protocol specified in AUTOSAR Classic Platform for Diagnostic Log and Trace (DLT): https://www.autosar.org/fileadmin/standards/R19-11/CP/AUTOSAR_SWS_DiagnosticLogAndTrace.pdf
There was a problem hiding this comment.
- check for IP
- compatibility to DLT has to be add
| - Log priorisation in case of ressource conflicts | ||
| - logging of early startup envents | ||
| - log filtering | ||
| - message loss detection |
There was a problem hiding this comment.
Message loss detection use cases:
- discarded log messages in case of internal buffer full
- lost messages detection based on global message counter (e.g.
MCNTfrom DLT protocol)
There was a problem hiding this comment.
hint: prio logic needs to define late
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall have low impact on overall system performance and provide QoS for handling overflows or dropping log messages. |
There was a problem hiding this comment.
split needed for atomic Reqs
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall be compatible with the Diagnostic Log and Trace (DLT) protocol, including support for DLT message format, sending and receiving DLT messages, and integration with existing DLT tools and infrastructure. |
There was a problem hiding this comment.
DLT can be added in some Abbreviations section and what DLT compatible means can be part of a separate Req attribute e.g., Additional Info = support for DLT message format, sending and receiving DLT messages, and integration with existing DLT tools, infrastructure...
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall be compatible with the Diagnostic Log and Trace (DLT) protocol, including support for DLT message format, sending and receiving DLT messages, and integration with existing DLT tools and infrastructure. |
There was a problem hiding this comment.
| The logging framework shall be compatible with the Diagnostic Log and Trace (DLT) protocol, including support for DLT message format, sending and receiving DLT messages, and integration with existing DLT tools and infrastructure. | |
| The logging framework shall be DLT compatible. |
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
|
|
||
| Glossary | ||
| ######## | ||
| - DLT - Diagnostic Log and Trace |
There was a problem hiding this comment.
The .. glossary:: directive would be suitable here.
See examples:
https://sublime-and-sphinx-guide.readthedocs.io/en/latest/glossary.html
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#glossary
There was a problem hiding this comment.
Done.
We need to discuss if the link in the requirement text to the glossary can lead to problems when exporting to other requirement tools.
| .. .. gd_temp:: Feature Requirements Templates | ||
| .. :id: gd_temp__log_req_feat_req | ||
| .. :status: valid | ||
| .. :complies: std_wp__iso26262__software_651, std_req__iso26262__support_641, std_req__iso26262__support_6421, std_req__iso26262__support_6425 | ||
|
|
||
| .. .. code-block:: rst |
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall ensure logs appear on stdout when running unit tests. |
There was a problem hiding this comment.
Logging to stdout can be useful not only for the tests. Maybe unit tests can be mentioned here as an example.
| The logging framework shall ensure logs appear on stdout when running unit tests. | |
| The logging framework shall support stdout as log sink, e.g. when running unit tests. |
The req title needs to be adapted accordingly.
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support QNX and Linux operating systems (encapsulated via OSAL). |
There was a problem hiding this comment.
The OSAL implementation for C++ is available at https://github.com/eclipse-score/baselibs/tree/main/score/os It's a dependency for mw::log and mw::com
AFAIK there is currently no clear consensus within the S-CORE Architecture Community regarding the future direction of OSAL and the specific content it should include.
| :reqtype: Interface | ||
| :security: NO | ||
| :safety: QM | ||
| :satisfies: stkh_req__dev_experience__logging_support |
There was a problem hiding this comment.
This also fits to stkh_req__dev_experience__prog_languages
| :satisfies: stkh_req__dev_experience__logging_support | |
| :satisfies: stkh_req__dev_experience__logging_support, stkh_req__dev_experience__prog_languages |
| :reqtype: Interface | ||
| :security: NO | ||
| :safety: QM | ||
| :satisfies: stkh_req__dev_experience__logging_support |
There was a problem hiding this comment.
| :satisfies: stkh_req__dev_experience__logging_support | |
| :satisfies: stkh_req__dev_experience__logging_support, stkh_req__overall_goals__enable_cooperation |
| :reqtype: Non-Functional | ||
| :security: YES | ||
| :safety: QM | ||
| :satisfies: stkh_req__dev_experience__logging_support |
There was a problem hiding this comment.
Does this req also fulfil stkh_req__dependability__security_features?
There was a problem hiding this comment.
I add the req due to Mandatory access control
| @@ -0,0 +1,25 @@ | |||
| .. | |||
| # ******************************************************************************* | |||
| # Copyright (c) 2024 Contributors to the Eclipse Foundation | |||
There was a problem hiding this comment.
| # Copyright (c) 2024 Contributors to the Eclipse Foundation | |
| # Copyright (c) 2025 Contributors to the Eclipse Foundation |
Same for other files
| ######## | ||
| - DLT - Diagnostic Log and Trace | ||
| - Framework - A structured and extensible foundation for developing specific types of functionality in this case, logging. It supplies a set of default behaviors and configurable options, allowing developers to tailor and extend its capabilities to meet their application and system need. | ||
| - Logging nodes - |
There was a problem hiding this comment.
| - Logging nodes - | |
| - Logging node - ECU or Partition (real or virtual) which generates log messages |
| - Logging nodes - | ||
| - Platform - | ||
| - Component - | ||
| - Logging severity level - e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT |
There was a problem hiding this comment.
| - Logging severity level - e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT | |
| - Log level - the severity of a log message, necessary to categorize logs based on their importance e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT |
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support log severity levels to categorize logs based on their importance. |
There was a problem hiding this comment.
| The logging framework shall support log severity levels to categorize logs based on their importance. | |
| The logging framework shall support a log level for each log entry. |
There was a problem hiding this comment.
where log level for is defined in glossary, with examples (see above)
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support logging of early startup events to capture critical initialization information. |
There was a problem hiding this comment.
Is that indeed a Logging Req, or more a Tracing Req (i.e. be able to capture early startup events and forward/route them as log messages) ?
There was a problem hiding this comment.
I think it is part of the complete logging. But I'm not sure whether the responsibility for this lies with a logging component outside the S-Core scope.
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support filtering by log levels (e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT). |
There was a problem hiding this comment.
| The logging framework shall support filtering by log levels (e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT). | |
| The logging framework shall support filtering by log levels. |
There was a problem hiding this comment.
(e.g., FATAL, ERROR, WARN, INFO, DEBUG, VERBOSE such as in DLT) is already in log level definition from the Glossary
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support user applications as log sources. |
There was a problem hiding this comment.
| The logging framework shall support user applications as log sources. | |
| The logging framework shall support user application as log source. |
|
|
||
| - The interface should support the ASIL level of the user function. | ||
| - Dependent on the Safety concept of the over all system, the logging should be classified accordingly. | ||
| That could be the case if the logging information are part of the verification strategy.. |
There was a problem hiding this comment.
I strongly suggest that for S-CORE we define what we do:
- either feature development supporting ASIL B
- or write an AoU that logging is not allowed to be used for safety functionality plus implement measures to support FFI (i.e. logging does not interfere with memory and also does not block too much runtime of the applications which uses it).
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall support on-demand functionality, such as enabling or disabling log storage. |
There was a problem hiding this comment.
better to have one Req per supported on-demand functionality
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall provide fallback configurations, such as application-wide or system-wide defaults. |
There was a problem hiding this comment.
| The logging framework shall provide fallback configurations, such as application-wide or system-wide defaults. | |
| The logging framework shall allow to restore default configurations. |
There was a problem hiding this comment.
These are two different requirements.
- fallback => in the event that no specific configuration is available, use the default config
- restore=> active call to restore the default config
The original requirement addresses the fallback case.
Should I include the restore case in a new requirement?
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall continue operation in case of recoverable errors. |
There was a problem hiding this comment.
| The logging framework shall continue operation in case of recoverable errors. | |
| In case of recoverable error, the logging framework shall continue the current operations. |
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall deactivate silently and set an error state reported on shutdown in case of non-recoverable errors. |
There was a problem hiding this comment.
| The logging framework shall deactivate silently and set an error state reported on shutdown in case of non-recoverable errors. | |
| In case of non-recoverable error, the logging framework shall deactivate silently and set an error state reported on shutdown. |
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall have low impact on overall system performance. |
There was a problem hiding this comment.
maybe low impact should be somehow / somewhere defined
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall provide QoS for handling overflows or dropping log messages. |
There was a problem hiding this comment.
Abbreviations section needed, e.g. for QoS
| :satisfies: stkh_req__dev_experience__logging_support | ||
| :status: valid | ||
|
|
||
| The logging framework shall be DLT (Diagnostic Log and Trace) compatible. |
There was a problem hiding this comment.
| The logging framework shall be DLT (Diagnostic Log and Trace) compatible. | |
| The logging framework shall be DLT compatible. |
There was a problem hiding this comment.
DLT which is used several times should be just part of Abbreviations / Glossary
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
- Update the requirement with the review findings. - Add a glossary. - Remove tracing FR.
| Motivation | ||
| ========== | ||
|
|
||
| - currently no solution available in the score platform |
There was a problem hiding this comment.
This should also be a motivation why S-CORE needs to solve this problem.
|
|
||
| - Possibility to provide an extension for custom types | ||
|
|
||
| Error handling |
There was a problem hiding this comment.
This should go into the error handling discussion that @ramceb is setting up.
|
|
||
| Norms/Standards | ||
| --------------- | ||
| The logging framework should be compatible with the Diagnostic Log and Trace (DLT) protocol. This includes: |
There was a problem hiding this comment.
should
Is this really optional?
| Safety Impact | ||
| ============= | ||
|
|
||
| - The interface should support the ASIL level of the user function. |
There was a problem hiding this comment.
Only the interface is not sufficient. The user application library in its fullness must support the ASIL level of the application.
|
|
||
| .. detailed design finding | ||
| Ideally, in a language like Rust, logging messages should be possible without allocations for individual logs. | ||
| Using the defacto standard log crate as facade, implementors of this facade should not allocate to write / forward log messages. |
There was a problem hiding this comment.
I see nothing about scheduling here.
A big concern for reproduction use cases is having no background threads or at least being able to conciously schedule background threads.
|
|
||
| To activate this feature, use the following feature flag: | ||
|
|
||
| ``experimental_Tracing`` |
There was a problem hiding this comment.
| ``experimental_Tracing`` | |
| ``experimental_tracing`` |
initial version of feature request #68