4. Tool Analysis¶
4.1. Potential Errors¶
4.1.1. Installation¶
Error identifier |
Use case |
Description |
Risk |
Mitigation |
Detectable |
|---|---|---|---|---|---|
|
Ferrocene was not correctly installed |
Undefined behavior |
NO |
4.1.2. Rust Driver¶
Error identifier |
Use case |
Description |
Risk |
Mitigation |
Detectable |
|---|---|---|---|---|---|
|
|
An used environment variable is set to an incorrect value |
Undefined behavior |
YES |
|
|
|
An invalid option is passed |
Undefined behavior |
YES |
|
|
|
Error diagnostics are not correctly emited |
Undefined behavior |
NO |
|
|
|
The output is generated with missing part |
Wrong code |
NO |
|
|
|
The behavior is incorrect because of concurrent modification |
Undefined behavior |
NO |
|
|
|
A warning is generated instead of an error |
Undefined behavior |
NO |
|
|
|
The compilation has a wrong behavior |
Wrong code |
NO |
|
|
|
An incomplete input is accepted leading to an undefined behavior |
Undefined behavior |
YES |
|
|
|
Some object files are silently not generated |
Use an artifact from a previous build |
NO |
4.1.3. Rust Front-End¶
Error identifier |
Use case |
Description |
Risk |
Mitigation |
Detectable |
|---|---|---|---|---|---|
|
|
Input has invalid contents |
Invalid code generated |
YES |
|
|
|
Error diagnostics is invalid |
Invalid code generated |
NO |
|
|
|
Invalid output generated from valid input |
Invalid code generated |
NO |
|
|
|
The behavior is incorrect because of concurrent modifications |
Invalid code generated |
NO |
|
|
|
Invalid input is accepted |
Undefined behavior |
YES |
|
|
|
Incorrect number of inputs are accepted |
Undefined behavior |
YES |
4.1.4. LLVM¶
Error identifier |
Use case |
Description |
Risk |
Mitigation |
Detectable |
|---|---|---|---|---|---|
|
|
Input parameter has invalid value |
Most likely LLVM will crash. Invalid code could also be generated |
NO |
|
|
|
An object file is invalid |
Invalid code generated |
NO |
|
|
|
An object file or static library is not correctly translated to machine code |
Undefined behavior |
NO |
|
|
|
The behavior is incorrect because of concurrent modifications |
Invalid code generated |
NO |
|
|
|
An object or static library exposes additional symbols |
Internal functionality might become callable from the outside |
NO |
|
|
|
Output does not contain expected variables or functions |
Invalid code generated |
|
NO |
4.1.5. Linking¶
Error identifier |
Use case |
Description |
Risk |
Mitigation |
Detectable |
|---|---|---|---|---|---|
|
Invalid input is accepted |
Undefined behavior |
NO |
||
|
Invalid executable or library produced |
Undefined behavior |
NO |
||
|
The behavior is incorrect because of concurrent modifications |
Undefined behavior |
NO |
||
|
Incorrect number of inputs are accepted |
Undefined behavior |
YES |
||
|
An input is missing |
Invalid code generated but won’t run |
YES |
||
|
Error diagnostics not emmited |
Invalid or missing code not detected by user may be linked against subsequent stage |
NO |
4.2. Detection Measures and Usage Restriction¶
Measure identifier |
Description |
|---|---|
|
The toolchain Installation shall be checked in order to ensure the validity of the build results. |
|
User must verify that environment variables used by the toolchain are correctly set. |
|
User must verify that the list of build actions is correct. |
|
Before building, the user must ensure that the build environment is clean of former compilation artifacts. |
|
All Warnings should be considered errors, the build should NOT display any warning. |
|
Concurrent file updates during the build operations are prohibited. |
|
Testing must be performed on the final application or libraries, or on any parts built, using an environment as close as possible to the final build. |
4.3. Potential Errors by Classes Traceability Matrix¶
Potential errors are the result of the HazOp analysis, it should be documented in the HazOp Report documents.
4.4. ISO 26262 Tool Classification¶
During this analysis, we highlighted some of the potential errors concerning Ferrocene that impacts the safety-related software code. Hence, the tool impact is TI2.
Moreover, this analysis shows us that the likelihood of detecting these potential errors is very low. Therefore, the tool error detection class is TD3.
Using clause 11.4.5.4 in part 8 of the [ISO-26262:2018] standard, we can conclude that in the worst case the Tool Classification Level is TCL3 and therefore we choose the following qualification methods:
1b. Evaluation of the tool development process in accordance with 11.4.8
1c. Validation of the software tool in accordance with 11.4.9
According to clause 11.4.2 in part 8 of the [ISO-26262:2018] standard, this choice depends on the user’s software development life-cycle and their validation strategy. The user has the responsibility to determine whether this level, or a better one, is applicable.
4.5. IEC 61508 Tool Classification¶
Ferrocene provides a development environment capable of compiling and linking programs for the target architecture to conform with industrial [IEC-61508:2010] class T3.
4.6. IEC 62304 Tool Classification¶
[IEC 62304:2006 + AMD 1:2015] does not provide an own scheme to classify and qualify tools used in its context, but recommends the application of techniques and tools as defined in [IEC-61508:2010]. Therefore, with the qualification of Ferrocene adhering to an IEC 61508 Tool Classification, Ferrocene can be used for development, release and maintenance of medical device software up to Class C.