TASKING Issues Field Help

Description

The full description of the issue, including any example(s).

Mitigation

Description of malfunctions and the appropriate safeguards, avoidance or workaround measures.

Type

The Type of an issue. Possible issue types are:

Status

The Status of an issue. Possible values are:

Component

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

Affected Toolchains

When a product contains multiple toolchains, this field shows the toolchain(s) that are affected by the problem.

Resolution

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.

Note: A patch does not necessarily include fixes for all toolchains present within the product. Please consult the supplied Release Note to find out which updated components are present in the patch.

Summary

A short summary of the Issue.

ID

The unique identifier of the Issue.

Inspector versions (in issue details)

When an Inspector product is available that can detect the problem described in the issue, the version information of the Inspector is listed here.

Inspector detector

Show the status of implementation of a detector in the inspector product:

Publised

This is the date that this issue is published on the TASKING Issues Portal

Updated

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.

History

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.

Date

The date of this update.

Field

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

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 malfunction varying from high integrity to low integrity. The criticality specifies the verification and validation efforts, intensity and rigor applied to V&V tasks in order to reduce the risk of systematic faults in the software being developed due to malfunctions of the software tool. The V&V task shall be executed by the user of the toolset in compliance with the safety standard applicable to the software being developed.

TASKING assigns SILs in accordance with the rules specified in the table below.

Criticality Description SIL
High Issue affects critical toolset integrity.
  • Issues assigned SIL 4 may cause malfunctioning of the software being developed.
  • This level applies to issues that may introduce a malfunction in the executable file created by the toolset (e.g. as a result of a code generation error).
  • This level also applies to issues where incorrect feedback is reported to the user which subsequently may lead to malfunctions in the software being developed (e.g. incorrect stack size estimate in map file).
  • There is no mitigation available for issues assigned SIL 4.
Important notices:
  • TASKING will reduce the SIL of issues initially rated at SIL 4 once a partial1 or a full mitigation2 is available.
  • The user of the toolset is responsible to ensure that the software being developed is not affected by SIL 4 issue.
4
Major Issue affects important toolset integrity.
  • Issues assigned SIL 3 may cause malfunctioning of the software being developed.
  • This level applies to issues that may fail to detect a potential malfunction in the generated code (e.g. undetected MISRA rule violation in user's software or incorrect DWARF debug information).
  • This level also applies to issues initially rated SIL 4 and reduced to SIL 3 once a partial mitigation1 becomes available (e.g. a compiler bug but can be avoided by applying MISRA rules).
  • Partial mitigation1 is possible.
Important notices:
  • TASKING will reduce the SIL of issues initially rated at SIL 3 once a full mitigation2 is available.
  • The user of the toolset is responsible to ensure that the software being developed is not affected by SIL 3 issues.
3
Moderate Issue affects toolset integrity, but workaround strategies can be implemented to compensate.
  • Issues assigned SIL 2 may cause malfunctioning of the software being developed.
  • This level applies to issues initially rated at a higher SIL once a full mitigation2 becomes available.
  • Full mitigation2 is possible.
Important notices:
  • TASKING does not apply SIL reduction on issues rated SIL 2.
  • The user of the toolset is responsible to ensure that the software being developed is not affected by SIL 2 issues. This can be achieved by applying the mitigation listed in the issue description.
2
Low Issue has no noticeable effect on toolset integrity but only creates inconvenience.
  • Issues assigned SIL 1 do not cause malfunctioning of the software being developed.
  • This level can apply to errors in the range from trivial to crucial, however a SIL 1 issue never causes safety issues in the software being developed.
    • Examples of trivial issues are: typos -- versus incorrect information which can be safety relevant -- in product documentation or tool output.
    • Examples of significant issues are: an error of the tool that causes the tool to fail to produce output.
  • From a safety perspective it is not required to apply any mitigation.
1

1) Partial mitigation: a mitigation that could fulfill the safety requirements. The verification and validation efforts could be high to ensure the mitigation is applied for all potential occurrences. The mitigation may cause performance degradation with respect to execution speed, timing, and memory footprint of the software being developed, also the usability of the tool may degrade.

2) Full mitigation: a mitigation that fulfills the safety requirements without causing significant verification and validation efforts. The mitigation may cause minimal performance degradation of the software being developed and does not affect the usability of the tool.