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 version(s) in which the issue is fixed.
A short summary of the Issue.
The unique identifier of the Issue.
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. A SIL is assigned to each requirement, test-case, and software module, where the SIL matches the level of the most critical function in the module. 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.