Requirements on Log and Trace (`LogAndTrace`)¶

返回本类索引

属性	值
平台	FO
类别	RS — 需求规范（Requirements Specification）
UID	350
规范版本	R25-11

本地文件¶

规范 PDF: F:\Work\Standards\01_Sources\FO_RS_LogAndTrace_350\AUTOSAR_FO_RS_LogAndTrace.pdf
ARXML 模型: F:\Work\Standards\01_Sources\FO_RS_LogAndTrace_350\AUTOSAR_FO_RS_LogAndTrace.arxml
纯文本全文: F:\Work\Standards\01_Sources\FO_RS_LogAndTrace_350\zzgen\FO_RS_LogAndTrace.complete.txt

文档简介¶

This following specification defines the functional and non-functional requirements of Log and Trace for AUTOSAR.

The focus of this document is to specify the requirements for:

The interface of Log and Trace to other CP:BSW modules / AP:Functional Clusters
The interface to CP:RTE/VFB / AP:ARA Tracing
The interface to CP:SWCs / AP:Applications
The transmission and storage format of the Log and Trace messages
The internal interface to the Log and Trace communication module
The general configuration of Log and Trace

The document does NOT specify the requirements for:

The transport layer of the communication over the Log and Trace communication module

章节详细内容¶

1. 范围 of Document¶

原文标题：Scope of Document

This following specification defines the functional and non-functional requirements of Log and Trace for AUTOSAR.

The focus of this document is to specify the requirements for:

The interface of Log and Trace to other CP:BSW modules / AP:Functional Clusters
The interface to CP:RTE/VFB / AP:ARA Tracing
The interface to CP:SWCs / AP:Applications
The transmission and storage format of the Log and Trace messages
The internal interface to the Log and Trace communication module
The general configuration of Log and Trace

The document does NOT specify the requirements for:

The transport layer of the communication over the Log and Trace communication module

2. Conventions to be used¶

The representation of requirements in AUTOSAR documents follows the table specified in , see .

The verbal forms for the expression of obligation specified in shall be used to indicate requirements, see .

3. 缩略语¶

原文标题：Acronyms and Abbreviations

The glossary below includes acronyms, abbreviations and definitions relevant to the Diagnostic Log and Trace module that are not included in .

Abbreviation / Acronym:	Description:
Log and trace message	A Log and Trace message contains all data and options to specify a Log and Trace event in a software.
User	The user of Log and Trace is the programmer of the software, which uses the Log and Trace API to generate Log and Trace messages.
Log	The user generates log messages on demand. Each time the user wants to show some information about state changes or value changes, he adds an API call to Log and Trace.
Trace	Trace messages can be generated by instrumentation of the code (e.g. VFB traces). The instrumented code calls the API of Log and Trace.
ECU ID	ECU ID is the name of each ECU.
Session ID	Session ID is the identification number of a log or trace session. If an Application is instantiated several times the log sessions get a new Session ID. A Application can have several log or trace sessions. A BSW module uses the module-number as Session ID.
Application ID	Application ID is a short name of the Application/BSW module.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

4. 需求规范¶

原文标题：Requirements Specification

This chapter describes all requirements driving the work to define Log and Trace in AUTOSAR.

5. 功能概述¶

原文标题：Functional Overview

Log and Trace provides a generic Logging and Tracing functionality for Applications and other modules.

Generally, Log and Trace provides the following functionalities:

Logging
Logging of errors, warnings and info messages from AUTOSAR Applications, providing a standardized AUTOSAR interface
Gather all Log and Trace messages from all AUTOSAR Applications Level and Middleware Level software in a centralized AUTOSAR module (Log and Trace).
Log messages from DET, DEM (Classic Platform)
Tracing
Trace RTE/VFB () (Classic Platform)
Control
Enable/Disable individual Log and Trace messages
Control trace levels individually by back channel
Generic
Log and Trace available during debugging and production phase
Access over standard diagnosis or platform specific test interface
Security mechanisms to prevent misuse in production phase

In addition, the following functionalities are provided for the Adaptive Platform:

Timestamps
In case a timestamp is required, the Log and Trace module provides the possibility of time-stamping both the logging as well as the tracing messages.

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

6. 功能性需求¶

原文标题：Functional Requirements

7. Log and trace 接口¶

原文标题：Log and trace interfaces

8. Generic¶

9. Logging shall 支持初始化 and registration.¶

原文标题：Logging shall support initialization and registration.

⌈ | Description: | Logging shall support to initialize the logging framework and to register the | |---|---|

source of logging information. | Rationale: | To be able to filter and associate logging information with the origin, it is | |---|---|

necessary that applications register themselves at the logging framework. | Applies To: | CP,AP | |---|---| | Dependencies: | - | | Use Case: | Associate logging information with the origin, apply filter settings and provide additional information. | | Supporting Material: | - |

⌋

10. Logging shall enable applications to provide meta information.¶

⌈ | Description: | Logging shall enable applications to provide additional information about | |---|---|

themselves. | Rationale: | Being able to identify the origin of generated logging information. | |---|---| | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Sort, filter and associate received logging information. | | Supporting Material: | - |

⌋

11. Logging shall enable applications to provide Logging Information.¶

⌈ | Description: | Logging shall enable applications to provide logging information. The logging | |---|---|

information shall include information about its severity. | Rationale: | While developing applications, it is important to get additional information what is going on internally of an application. | |---|---| | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Getting internal information of an application, e.g.: Variable values, the current internal state of a state machine and other information. | | Supporting Material: | - |

⌋

12. Logging shall enable 追踪 of communication between applications.¶

原文标题：Logging shall enable tracing of communication between applications.

⌈ | Description: | It shall be possible to trace the communication between applications. | |---|---| | Rationale: | More and more applications are integrated on one ECU. As a consequence, the communication between applications is done locally and not over an external traceable bus like CAN. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Trace the communication between applications. | | Supporting Material: | - |

⌋

13. Logging shall 支持 grouping of Logging Information.¶

原文标题：Logging shall support grouping of Logging Information.

⌈ | Description: | Logging shall support to logically group logging information. | |---|---| | Rationale: | Cluster logging information which logically belongs together. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Associate or filter all logging information which belongs together. | | Supporting Material: | - |

⌋

14. Logging shall allow to select the destination of logging information.¶

⌈ | Description: | Logging shall allow to select the destination of the provided logging information. | |---|---| | Rationale: | There are different possibilities where the logging information can be stored. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Forward logging information to the console, to the file system or to send it via the communication bus. | | Supporting Material: | - |

⌋

15. Logging shall provide early logging capabilities.¶

⌈ | Description: | Logging framework shall provide early logging possibility. The API shall be able to handle log message attempts as well as creating new log contexts instances before the main initialization phase of the Logging back-end was accomplished. | |---|---| | Rationale: | Calling the initialization procedure at earliest is possible when the program code is executed within the main event loop. Before that, applications might create global/static objects which constructors might already log useful information. Since global/static object are instantiated before the main event loop enters, the Logging framework must support calls to all its interfaces without crashing. Ideally it shall buffer log attempts (an unspecified amount) and statically created log context instances and process them ASAP after the initialization phase. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Create log contexts and/or initiate log messages before initialization phase of |

the Logging back-end was accomplished. | Supporting Material: | - | |---|---|

⌋

16. The Log and Trace shall transmit Log and Trace messages from several sources over a communication 接口 to a receiving external client.¶

原文标题：The Log and Trace shall transmit Log and Trace messages from several sources over a communication interface to a receiving external client.

⌈ | Description: | The Log and Trace module shall be a BSW module. It shall receive Log and Trace messages from several sources, like Applications, some BSW modules and the RTE. These messages may be transmitted over a communication interface to an external client. | |---|---|

Log and trace is a debugging mechanism needed by a lot of ECU's. A Log and Trace module shall provide a mechanism to gather Log and Trace messages from several sources. The Log and Trace module buffers the Log and Trace entries if necessary and shall have a connection to an external client. | Rationale: | Each Tier1 uses its own mechanisms to provide such a logging interface, using some internal or external debugging interfaces. The format of the logging content also differs from ECU to ECU. When testing several ECU's, many different tools and parsers are needed to get the right information out of the logs. A standard Diagnostic Logging Component with standardized logging content may help to reduce the testing efforts and enable new automated testing mechanisms. Also the number of tools could be reduced by a standard logging content and protocol. | |---|---|

……本章内容较长已节选，完整内容见「本地文件」中的纯文本全文。

17. All Log and Trace messages sent by an ECU shall have a standardized transmission format and a standardized storage format.¶

⌈ | Description: | A specified format shall be defined, which covers all requirements of Log and Trace. Some examples of the information stored in a log or trace message are the source, the context and the timestamp of the message to be able to filter the Log and Trace messages. | |---|---| | Rationale: | Since logging and tracing is an important mechanism for testability and proofing product quality, it is necessary to standardize the transmitted and stored data format. This is important for archiving, comparing and analyzing of log or trace messages. Also it may be possible to build common tools to interpret the incoming data. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Applications sends a log message |

Log and Trace sends the message over an interface to a data storing external client
The stored data of different ECU's are interpreted by the external client
Log and trace messages from different ECU's can be merged to understand relationship of behavior from distributed functionality | Supporting Material: | |---|

⌋

18. 接口 for Applications¶

原文标题：Interface for Applications

19. Applications shall have the possibility to send log or trace messages to the Log and Trace 模块.¶

原文标题：Applications shall have the possibility to send log or trace messages to the Log and Trace module.

⌈ | Description: | Log and Trace shall offer a generic interface for Applications independent from the type of Log and Trace message. | |---|---| | Rationale: | To reduce the amount of interfaces a generic and message independent interface may be implemented. | | Applies To: | AP, CP | | Dependencies: | - | | Use Case: | * Interfacing Application with Log and Trace module |

Tracing or logging messages from Applications | Supporting Material: | |---|

⌋

20. Logging shall provide an 接口 for logging information.¶

原文标题：Logging shall provide an interface for logging information.

⌈ | Description: | Logging shall provide interfaces for applications to forward its logging | |---|---|

information, including the associated severity level. | Rationale: | Forward logging information to the logging framework. | |---|---| | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Forward logging information to a logging framework for further processing (e.g. store it locally or forward it to the communication bus). | | Supporting Material: | - |

⌋

21. Logging shall be able to 句柄 raw buffer content as logging information.¶

原文标题：Logging shall be able to handle raw buffer content as logging information.

⌈ | Description: | Logging shall support to provide the content of a raw buffer as logging | |---|---|

information. | Rationale: | The original content of a buffer might be of interest for developing purpose. | |---|---| | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Get the exact raw data which is located in the memory. | | Supporting Material: | - |

⌋

22. Logging shall enable applications to check the current severity level.¶

⌈ | Description: | Logging shall provide the possibility for applications to check the current active severity level. | |---|---| | Rationale: | To avoid unnecessary CPU and/or memory consumption, which is needed for the generation of logging information, applications shall have the possibility to first check whether or not its created logging information will be filtered out anyway by the underlying logging framework. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Avoidance of unnecessary CPU and/or memory consumption. | | Supporting Material: | - |

⌋

23. Logging shall provide conversion functions for hexadecimal and binary values.¶

⌈ | Description: | Logging shall provide the possibility for applications to convert decimal values into the hexadecimal or binary system. | |---|---| | Rationale: | Provide some debug information as a hexadecimal or as a binary value, instead of a decimal value. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Providing logging information as hexadecimal value or as binary value. | | Supporting Material: | - |

⌋

24. The Log and Trace shall provide the actual set of log levels and the trace status to an Application.¶

⌈ | Description: | Application shall be aware of its log levels and trace status in order not to generate unnecessary Log and Trace messages. Log level and trace status should be checked by the Applications before sending the messages. | |---|---| | Rationale: | The generation of unnecessary load on the communication interface and for the system has to be avoided. The Log and Trace shall provide information about the actual configuration. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Control of the log levels and of the trace status | | Supporting Material: | - |

⌋

25. For each Application the 接口 to Log and Trace shall be configured.¶

原文标题：For each Application the interface to Log and Trace shall be configured.

⌈ | Description: | The generation of the Log and Trace interface of each Application shall be enabled by the configuration. | |---|---| | Rationale: | Only the configured interfaces to the Applications, which are using Log and Trace, shall be generated. | | Applies To: | CP,AP | | Dependencies: | - |

Use Case: | Supporting Material: | - | |---|---|

⌋

26. DEM trace 接口¶

原文标题：DEM trace interface

27. The DEM shall forward 错误 events to the Log and Trace 模块.¶

原文标题：The DEM shall forward error events to the Log and Trace module.

⌈ | Description: | The DEM may forward error events to the Log and Trace module. | |---|---| | Rationale: | It may be possible to get an overview of all error messages in an ECU. It may be possible to set them in the correct context with the error events reported by DEM. This makes an analysis of the reported errors more efficient and gives a correct picture of a failure situation. | | Applies To: | CP | | Dependencies: | - | | Use Case: | A Application or BSW module sets an DTC in the DEM. The DEM forwards this event to the Log and Trace. The Log and Trace turns these events in the Log and Trace format and sends it over a communication interface to a Log and Trace external client. | | Supporting Material: | - |

⌋

28. RTE/VFB trace 接口¶

原文标题：RTE/VFB trace interface

29. RTE shall provide an 接口 for Log and Trace to trace RTE/VFB calls.¶

原文标题：RTE shall provide an interface for Log and Trace to trace RTE/VFB calls.

⌈ | Description: | RTE shall provide the possibility to trace the VFB. | |---|---| | Rationale: | In the future more and more Applications will be integrated in one ECU. As a consequence the communication between Application is done locally and not over an external traceable bus like CAN or Flexray. It is important to trace the internal communication over RTE/VFB. | | Applies To: | CP | | Dependencies: | - | | Use Case: | * Trace of VFB interface |

Access to VFB for advanced diagnostic services | Supporting Material: | - | |---|---|

⌋

30. The Log and Trace shall implement an 接口 to trace the RTE/VFB.¶

原文标题：The Log and Trace shall implement an interface to trace the RTE/VFB.

⌈ | Description: | VFB-Tracing shall be provided to the RTE generation system. The Log and Trace module shall implement the handling of the RTE/VFB trace events. | |---|---| | Rationale: | To understand the communication between the Applications it is important to trace all function calls to the Applications except the RTE system function calls. | | Applies To: | CP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

31. A global switch shall be defined to switch on and off the RTE 追踪.¶

原文标题：A global switch shall be defined to switch on and off the RTE tracing.

⌈ | Description: | There shall be a global switch to turn on and off the RTE tracing of Log and Trace at configuration time and at run time. | |---|---| | Rationale: | To have a high level activation for all RTE tracing messages a global switch is needed. | | Applies To: | CP | | Dependencies: | - | | Use Case: | Turning all tracing events for Log and Trace on/off | | Supporting Material: | - |

⌋

32. The Log and Trace shall implement the 处理 of the RTE/VFB trace events.¶

原文标题：The Log and Trace shall implement the handling of the RTE/VFB trace events.

⌈ | Description: | The Log and Trace may implement the handling of the RTE/VFB trace events. | |---|---|

The groups may be configured at configuration time and the events may be assigned to one group. At run time the log level of each group can be set individually. | Rationale: | To understand the communication between the Applications it is important to trace the function calls of an Application. | |---|---| | Applies To: | CP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

33. Log and Trace shall provide a solution to trace events linked to implicit communication mechanism.¶

⌈ | Description: | Log and Trace may provide a solution to trace events linked to implicit communication mechanism. The implicit communication may be traced at runnable invocation and termination. | |---|---| | Rationale: | From the point of view of an Application no extra routine for receiving or sending signals (Sender Receiver Communication) with implicit sending/receiving is called. |

The RTE manages the copying of the data before invocation and after exiting. | Applies To: | CP | |---|---| | Dependencies: | - | | Use Case: | Tracing implicit communication of Applications | | Supporting Material: | - |

⌋

34. Format of Log and Trace message¶

35. The transmitted 数据 shall be packetized.¶

原文标题：The transmitted data shall be packetized.

⌈ | Description: | The Log and Trace messages shall be packet oriented. Each packet shall have one or several headers and a payload. | |---|---|

The headers may be used for identifying, filtering and classifying the Log and Trace message. The payload shall contain the parameters given from the Application or BSW. | Rationale: | Log and Trace shall not care about the under laying transport protocol. Log and Trace shall define the log or trace message format. | |---|---| | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

36. The 传输 format shall be binary.¶

原文标题：The transport format shall be binary.

⌈ | Description: | The Log and Trace messages shall be in binary format. This is necessary for reducing the bandwidth and the CPU consumption. | |---|---| | Rationale: | Scope of the Log and Trace component is to Log and Trace events without perturbing the ECU behavior. CPU consumption and bandwidth occupation may be reduced by using a binary format for the protocol. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

37. The format shall deal with Big and Little Endianess.¶

⌈ | Description: | The Endian format shall be considered in the message specification. The message shall signal which Endianess mode is actually used. | |---|---| | Rationale: | Big and Little Endianess of data representation has mixed occurrences in automotive ECUs. The message format shall be able to deal with both. To reduce CPU load it shall be possible to transport the data in the corresponding format of the ECU. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Marker for format | | Supporting Material: | - |

⌋

38. Each Log and Trace message shall contain a timestamp, which will be added to the message during reception of the message in the Log and Trace 模块.¶

原文标题：Each Log and Trace message shall contain a timestamp, which will be added to the message during reception of the message in the Log and Trace module.

⌈ | Description: | Each Log and Trace message may contain a timestamp, which shall be added to the message during reception of the message in the Log and Trace module. | |---|---| | Rationale: | For comparing and analyzing complex systems a timestamp is important. The time shall be in a defined granularity. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

39. A global message counter shall be implemented, to detect messages loss.¶

⌈ | Description: | Every time a message from an Application is received by the Log and Trace module or other software module, it shall increment its global messages counter and set the counter in the message. | |---|---| | Rationale: | It is important to know if a message is lost. A receiving external client may then detect if messages are lost (e.g.because of a buffer overflow in Log and Trace or network loss). | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

40. For each log message, a log level shall be provided.¶

⌈ | Description: | Log levels shall be for example error, fatal, debug, information or verbose. | |---|---| | Rationale: | Standard for logging tools | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

41. The Log and Trace message shall contain a parameter, which represents the source of the Log and Trace message.¶

⌈ | Description: | The Log and Trace message may contain a parameter, which represents the source of the Log and Trace message. | |---|---| | Rationale: | The source can be identified by the Session ID of the port interface (port defined argument value) which was used to send the message from Application to Log and Trace. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

42. There shall be a logical grouping for log messages by using different identifiers.¶

⌈ | Description: | There shall be additional parameters describing the group of the Log and Trace message. | |---|---| | Rationale: | Identifying some logically groups of Log and Trace to define some filtering action on the external client. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

43. Each ECU shall have its unique ECU ID.¶

⌈ | Description: | Each ECU may have its unique ECU ID, which may be a parameter of each Log and Trace message. | |---|---| | Rationale: | An external client receives tracing from different ECU's so it's important to know the source. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Distinguish tracing from different ECU's | | Supporting Material: | - |

⌋

44. The payload shall 传输 the parameters of a Log and Trace message.¶

原文标题：The payload shall transport the parameters of a Log and Trace message.

⌈ | Description: | In the payload the parameters of each Log and Trace message from the Application shall be transported. It may be possible to transport more than one parameter. | |---|---| | Rationale: | - | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

45. It shall be possible to transmit the parameters in a raw format.¶

⌈ | Description: | In most cases the parameter shall be transmitted in the raw format. This means that a separate file shall be provided containing the information about the transmitted parameters. | |---|---| | Rationale: | The non-verbose mode is for saving memory and bandwidth, because on the ECU only the ID's of the Log and Trace messages shall be stored. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Interpreting binary data | | Supporting Material: | - |

⌋

46. There shall be the possibility to transmit the parameters with additional information about themselves (self-description).¶

⌈ | Description: | The Log and Trace messages shall contain a description of the parameters in verbose mode. No additional description file needs to be provided in this case. | |---|---| | Rationale: | In the verbose mode all parameters of the payload contain a self-description of their own type (e.g. integer/float, bit length) and some additional information (e.g. variable name, unit, etc). | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Interpreting binary data | | Supporting Material: | - |

⌋

47. It shall be possible to transmit ASCII text in log or trace messages.¶

⌈ | Description: | Because Log and Trace messages often consists of texts, there shall be the possibility to transmit text strings. It may be possible to replace the given text by an ID which may be replaced by the text in the external client (Compare verbose - non-verbose mode). | |---|---| | Rationale: | In small ECU strings can not be stored because of their memory usage. For this reasons these strings may be replaced by a message ID. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

48. The 数据 in non-verbose 模式 shall be described by an extra 文件¶

原文标题：The data in non-verbose mode shall be described by an extra file

⌈ | Description: | The data in non-verbose mode need to be described by an extra file. This file may be in a ARXML format. | |---|---| | Rationale: | In small ECUs memory is very limited, so temporarily buffered data shall be very small. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

49. Each message in non-verbose 模式 shall have a unique Message ID significant for identifying the source of the 追踪.¶

原文标题：Each message in non-verbose mode shall have a unique Message ID significant for identifying the source of the tracing.

⌈ | Description: | Each message may have a unique identifier significant for identifying the source of the tracing. The ID of a specific message shall be permanent over the developing phase and shall be unique for a given ECU. | |---|---| | Rationale: | Easy identifying the right information in the Log and Trace message is very important. Unique message IDs helps doing this. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | - | | Supporting Material: | - |

⌋

50. 传输接口¶

原文标题：Transport interfaces

51. Generic¶

52. A 控制 message shall be implemented to permit the external client to evaluate the round trip time.¶

原文标题：A control message shall be implemented to permit the external client to evaluate the round trip time.

⌈ | Description: | A control message shall be implemented to permit the external client to evaluate the round trip time. The external client shall use this message to synchronize the individual Log and Trace messages from the different ECUs. | |---|---| | Rationale: | The Log and Trace time information may enable a user to understand what happens if there is a correlation among the recorded events. It is important to be able to refer all the events logged to an absolute time scale. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * An external client is able to synchronize packet reception from different sources |

A round trip time calculation for each ECU is done
In each message the ECUs local time is transmitted
For every message from several ECUs a global time line can be calculated | Supporting Material: | - | |---|---|

⌋

53. A protection against unauthorized access in production phase shall be provided.¶

⌈ | Description: | In production phase, the communication module (see RS_LT_00034) shall be disabled by default. In production phase Log and Trace shall use the security mechanisms provided by DCM to handle the access to the Log and Trace messages. A mechanism shall be implemented to enable the communication module for testing phase permanently. | |---|---| | Rationale: | Only authorized accesses to Log and Trace shall be allowed during production phase to avoid misuse. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | Avoid Log and Trace misuse | | Supporting Material: | - |

⌋

54. Logging shall be able to monitor and shape the amount of Log and Trace events.¶

⌈ | Description: | Log and Trace may shape the traffic bandwidth depending on which transport interface is used for communication. The traffic shaping shall be done at runtime. | |---|---| | Rationale: | Since Log and Trace shall be used also in production phase, it is important that the traffic produced by the Log and Trace component will not cause an overload of the network and the ECU resources. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Bandwidth occupation has to be controlled |

Bandwidth configuration has to be permitted | Supporting Material: | - | |---|---|

⌋

55. The Log and Trace shall be configurable at runtime.¶

⌈ | Description: | Log and Trace shall be configurable at runtime. Log and Trace shall have for this propose runtime configurable variables which are initialized with the corresponding configuration parameters. It shall be possible to query the Log and Trace runtime configuration. The configuration variables shall be writeable and readable over with some control .mechanism triggered remotely. | |---|---| | Rationale: | To adapt Log and Trace behavior to ECU and network resources it is important to have the capability of configuring it. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Changing default levels with storing in NVRAM |

Query Log and Trace state | Supporting Material: | - | |---|---|

⌋

56. A 协议 shall be implemented to be able to set and query the trace status and log levels of Log and Trace sources of each ECU.¶

原文标题：A protocol shall be implemented to be able to set and query the trace status and log levels of Log and Trace sources of each ECU.

⌈ | Description: | Log and Trace shall support control messages to set the trace status and log level of each source of each ECU. | |---|---| | Rationale: | - | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Enabling/disabling trace and log messages at different levels. |

Set the level of the log messages generated by different sources of each ECU. | Supporting Material: | - | |---|---|

⌋

57. A list of all Log and Trace sources of an ECU shall be accessible from the external client.¶

⌈ | Description: | It shall be possible to get a list of all Application IDs and context IDs with corresponding trace status and log levels which are registered to the Log and Trace module.Each Application or BSW module which wants to produce trace or log messages shall register to the Log and Trace module. | |---|---| | Rationale: | Users need to know what information can be traced or logged in order to monitor ECU activity. | | Applies To: | CP,AP | | Dependencies: | - | | Use Case: | * Log messages from different ECU's can be merged to understand relationship of behavior from distributed Applications. |

Set the level of the tracing generated by different sources of each ECU. | Supporting Material: | - | |---|---|

⌋

其余 35 章（内容从略，见纯文本全文）¶

Communication 接口
Log and Trace shall 支持 a generic API for communicating over a Log and Trace communication 模块.
DCM 传输接口
The DCM shall provide an 接口 for Log and Trace to 传输 Log and Trace messages over a 诊断 session.
Operational 功能
初始化 and 关机
The Log and Trace shall provide a buffer for storing Log and Trace messages before 初始化
Normal operation
There shall be a buffer to store Log and Trace message locally.
A mechanism shall be implemented to be able to set the trace status and log levels of registered Application IDs and context IDs of each Application.
The Log and Trace shall provide the possibility to store 配置数据 in a persistent way.
The Log and Trace 组件 shall be able to filter Log and Trace messages.
AUTOSAR Log and Trace shall 支持 harmonized logging.
Non-Functional 需求
[RS_LT_00041
[RS_LT_00042
[RS_LT_00059
[RS_LT_00060
[RS_LT_00061
[RS_LT_00062
References
附录
Change history of AUTOSAR traceable items
Traceable item history of this document according to AUTOSAR Release R23-11
Added 需求 in R23-11
Changed 需求 in R23-11
Deleted 需求 in R23-11
Traceable item history of this document according to AUTOSAR Release R24-11
Added 需求 in R24-11
Changed 需求 in R24-11
Deleted 需求 in R24-11
Traceable item history of this document according to AUTOSAR Release R25-11
Added 需求 in R25-11
Changed 需求 in R25-11
Deleted 需求 in R25-11

Requirements on Log and Trace (LogAndTrace)¶

本地文件¶

文档简介¶

章节详细内容¶

1. 范围 of Document¶

2. Conventions to be used¶

3. 缩略语¶

4. 需求规范¶

5. 功能概述¶

6. 功能性需求¶

7. Log and trace 接口¶

8. Generic¶

9. Logging shall 支持初始化 and registration.¶

10. Logging shall enable applications to provide meta information.¶

11. Logging shall enable applications to provide Logging Information.¶

12. Logging shall enable 追踪 of communication between applications.¶

13. Logging shall 支持 grouping of Logging Information.¶

14. Logging shall allow to select the destination of logging information.¶

15. Logging shall provide early logging capabilities.¶

16. The Log and Trace shall transmit Log and Trace messages from several sources over a communication 接口 to a receiving external client.¶

17. All Log and Trace messages sent by an ECU shall have a standardized transmission format and a standardized storage format.¶

18. 接口 for Applications¶

19. Applications shall have the possibility to send log or trace messages to the Log and Trace 模块.¶

20. Logging shall provide an 接口 for logging information.¶

21. Logging shall be able to 句柄 raw buffer content as logging information.¶

22. Logging shall enable applications to check the current severity level.¶

23. Logging shall provide conversion functions for hexadecimal and binary values.¶

24. The Log and Trace shall provide the actual set of log levels and the trace status to an Application.¶

25. For each Application the 接口 to Log and Trace shall be configured.¶

26. DEM trace 接口¶

27. The DEM shall forward 错误 events to the Log and Trace 模块.¶

28. RTE/VFB trace 接口¶

29. RTE shall provide an 接口 for Log and Trace to trace RTE/VFB calls.¶

30. The Log and Trace shall implement an 接口 to trace the RTE/VFB.¶

31. A global switch shall be defined to switch on and off the RTE 追踪.¶

32. The Log and Trace shall implement the 处理 of the RTE/VFB trace events.¶

33. Log and Trace shall provide a solution to trace events linked to implicit communication mechanism.¶

34. Format of Log and Trace message¶

35. The transmitted 数据 shall be packetized.¶

36. The 传输 format shall be binary.¶

37. The format shall deal with Big and Little Endianess.¶

38. Each Log and Trace message shall contain a timestamp, which will be added to the message during reception of the message in the Log and Trace 模块.¶

39. A global message counter shall be implemented, to detect messages loss.¶

40. For each log message, a log level shall be provided.¶

41. The Log and Trace message shall contain a parameter, which represents the source of the Log and Trace message.¶

42. There shall be a logical grouping for log messages by using different identifiers.¶

43. Each ECU shall have its unique ECU ID.¶

44. The payload shall 传输 the parameters of a Log and Trace message.¶

45. It shall be possible to transmit the parameters in a raw format.¶

46. There shall be the possibility to transmit the parameters with additional information about themselves (self-description).¶

47. It shall be possible to transmit ASCII text in log or trace messages.¶

48. The 数据 in non-verbose 模式 shall be described by an extra 文件¶

49. Each message in non-verbose 模式 shall have a unique Message ID significant for identifying the source of the 追踪.¶

50. 传输接口¶

51. Generic¶

52. A 控制 message shall be implemented to permit the external client to evaluate the round trip time.¶

53. A protection against unauthorized access in production phase shall be provided.¶

54. Logging shall be able to monitor and shape the amount of Log and Trace events.¶

55. The Log and Trace shall be configurable at runtime.¶

56. A 协议 shall be implemented to be able to set and query the trace status and log levels of Log and Trace sources of each ECU.¶

57. A list of all Log and Trace sources of an ECU shall be accessible from the external client.¶

其余 35 章（内容从略，见纯文本全文）¶

Requirements on Log and Trace (`LogAndTrace`)¶