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.

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.
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.

Type

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.

Status

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

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:

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.

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.

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:

Available
Available, manual guidance
Planned for Inspector inspector version
Planned for future version
Not feasible
Not planned

Discovered with

Tells how the problem is discovered, for example in customer code or with a compiler testing tool.
This field will not be visible when empty.

Reproducibility

The reproducibility of the problem: Always, Sometimes or Once.
This field will not be visible when empty.

Impact

The likelyhood that the problem affects real world application code.
This field will not be visible when empty.

Actions to trigger the problem

The actions to be taken to trigger the problem.
This field will not be visible when empty.

Observed behavior

The behavior that is observed when the problem is triggered.
This field will not be visible when empty.

Expected behavior

The behavior that is expected in the situation where the problem is triggered.
This field will not be visible when empty.

Tool options

In case of a command line tool, what tool options are essential to trigger the problem.
This field will not be visible when empty.

Code patterns to trigger the problem

If the problem is triggered by source code, this field describes the code patterns required to trigger the problem.
This field will not be visible when empty.

Publised

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.

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 software tool 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 partial¹ or a full mitigation² 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 mitigation¹ becomes available (e.g. a compiler bug but can be avoided by applying MISRA rules). Partial mitigation¹ is possible. Important notices: TASKING will reduce the SIL of issues initially rated at SIL 3 once a full mitigation² 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 mitigation² becomes available. Full mitigation² 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

¹⁾ 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.

²⁾ 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.