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:

Affected versions

The product versions for which this issue is listed as an open issue.

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.


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.

Old Value

The previous value of the field that has been updated.

New Value

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:

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.