TASKING Issues Field Help
The full description of the issue, including any example(s).
Description of malfunctions and the appropriate safeguards, avoidance or workaround measures.
The Type of an issue. Possible issue types are:
- Improvement: An improvement or enhancement to an existing feature.
- New Feature: A new feature of the product.
- Problem: An issue which impairs or prevents the functions of the product.
The Status of an issue. Possible values are:
- Open: the issue is not yet solved.
- Closed: the issue has been closed with a resolution. The issue is either fixed, will not be fixed, is not a problem or cannot be reproduced.
Component: The part of the product affected by this issue.
The Resolution for this issue. Possible values are:
- Fixed: This issue has been fixed.
- Won't Fix: The problem described is an issue which will never be fixed.
- Not a problem: The issue described is not a problem, but defined behavior.
- Cannot Reproduce: All attempts at reproducing this issue failed, or not enough information was
available to reproduce the issue.
The product versions for which this issue is listed as an open issue.
The product version(s) in which the issue is fixed.
A short summary of the Issue.
The unique identifier of the Issue.
This is the date that this issue is published on the TASKING Issues Portal
This is the date that this issue is updated on the TASKING Issues Portal. Update date recording in the TASKING Issues Portal has started 2020-01-01. Updates before that date are not reflected in the Updated date.
The update history of the issue. History recording in the TASKING Issues Portal has started 2020-01-01. Before that time the history table will not show details of the changed fields. The publication date of these issues is accurate.
The date of this update.
The issue field that has been updated.
The previous value of the field that has been updated.
The new value of the field that has been updated.
SIL (Software Integrity Level): A four-valued classification to indicate the criticality of (potential) malfunctions with regards to the integrity of toolset behavior based on IEEE-1012 Standard for Software Verification and Validation.
Four software integrity levels describe the criticality of the issue varying from high integrity to low integrity. The "criticality" defines the consequences of a malfunction and is described in the table below:
|| Selected issue affects critical toolset integrity.
- This level applies to issues that may trigger a malfunction in the generated code. If the source code violates MISRA rules the level can be reduced.
- This level applies to issues that provide incorrect feedback to the user which may result in incorrect code (e.g. incorrect stack size estimate in map file).
- No mitigation is possible, i.e. it is not possible to lessen the risk by lowering the probability of the risk event's occurrence or reducing the effect should it occur.
- If the error is introduced by using the C library, then the SIL can be reduced one step because the C library is not validated for use in safety critical applications.
|| Selected issue affects important toolset integrity.
- This level applies to issues that may not detect a malfunction in the generated code or may affect code generation but without introducing a malfunction in the generated code. E.g incorrect feedback to a user (such as a MISRA violation that is not recognized).
- Partial-to-complete mitigation is possible.
|| Selected issue affects toolset integrity, but workaround strategies can be implemented to compensate.
- Complete mitigation is possible.
- This level is often assigned to errors related to debugging. If, for example, the debugger shows incorrect information (e.g. incorrect value of a variable), either caused by incorrect debug info or interpretation of the debug info, then this level applies. One could argue that such error is at level SIL-3, but if a workaround is available e.g. by inspecting the memory or register content the level is SIL-2.
|| Selected issue has no noticeable effect on toolset integrity but only creates inconvenience.
- Mitigation is not required.
- Build errors like assertion errors, link errors etc. which do not produce an output file.
- The tool exits with an unexpected return value.