What's needed?
Here is an example of a diagnostics message:
|
message ElectricalComponentDiagnostic { |
|
// A standardized error code representing the category of the issue. |
|
ElectricalComponentDiagnosticCode diagnostic_code = 1; |
|
|
|
// Optional vendor-provided error code for the error, for vendor-specific |
|
// insights or more granular diagnostics. |
|
optional uint32 vendor_error_code = 2; |
|
|
|
// Optional human-readable message providing additional context. |
|
string message = 3; |
|
} |
|
// List of non-critical warnings detected for the component. |
|
// |
|
// !!! note |
|
// Warnings may be reported even when the component is operational. |
|
// No duplicate warning codes allowed. |
|
repeated ElectricalComponentDiagnostic warnings = 3; |
|
|
|
// List of critical errors currently affecting the component. |
|
// |
|
// !!! note |
|
// This list is expected to be populated only when the component is in an |
|
// error state. |
|
// No duplicate error codes allowed. |
|
repeated ElectricalComponentDiagnostic errors = 4; |
We use the same set of diagnostic error codes for both errors and warnings. The challenge is that it is not clear which of these diagnostic codes are errors, and which are warnings.
For a lot of cases, it is a matter of severity, e.g., this one:
|
ELECTRICAL_COMPONENT_DIAGNOSTIC_CODE_UNDERTEMPERATURE = 9; |
But in some cases, it is always going to be an error, e.g., this one:
|
ELECTRICAL_COMPONENT_DIAGNOSTIC_CODE_PRECHARGE_ERROR = 12; |
The challenge is to communicate clearly how these codes will be used in the API in practice.
Proposed solution
There are two non-clear approaches as to address this issue as of now:
Option 1 - Use separate diagnostic code enums for errors and warning
Option 2 - Clarify in documentation how it may behave with respect to severity. So far, the consensus is to go with this approach.
Use cases
No response
Alternatives and workarounds
No response
Additional context
No response
