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:


The Status of an issue. Possible values are:


Component: The part of the product affected by this issue.


The Resolution for this issue. Possible values are:

Solved in version

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:

Criticality Description SIL
High 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.
Major 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.
Moderate 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.
Low 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.