FMEA

The FMEA is done on the “first zoom level” of the architecture, the main workflow.

The relevant elements are annotated by oval labels, see also the diagram legend.

Fault Model

The following analysis is based on this generic fault model for activity diagrams:

Element Type	Error ID	Generic Error Description
Data storage	DS1	Stored data changed before read operation
	DS2	New data not stored / keeps old data / stuck at specific value
Data flow	DF1	Transferred data changed
	DF2	Transferred data lost
	DF3	Data stored at / read from wrong location in data store
	DF4	Data transferred to wrong data store
Processing	PR1	Calculates wrong results
	PR2	Processing is skipped
	PR3	Processing too slow/fast
Control flow	CF1	Control flow stops
	CF2	Control flow proceeds to wrong process

If more than one error is identified for the same element with the same error ID, a counter is added, e.g. PR1.1, PR1.2, etc.

In the following sections, references to files are shown which end with _spec.rb. These files are test files which can be found in the spec folder of the dox_trace extension, e.g. <dox_trace root>/spec/asil_spec.rb.

Generalized Errors

The following errors are analyzed generically and not on architectural element level.

Error ID	General Error Description	Measures
DF1, DF2, DF3	Data is corrupted or lost during file access or wrong files are accessed.	This tool runs without network access or memory queues. It is assumed that underlying layers like Python or the OS are qualified. Potential issues with data are analyzed in “Data storage” and “Processing” elements.
DF4	Every data store type exists only once in the system, e.g. RST files cannot be stored in Exit code.	Trying to do something like this will lead to a program exception. dox_trace will terminate with an exit code != 0.
PR3	dox_trace has no timing constraints. But a too slow execution might frustrate the user, so that the user removes the mandatory check on the code review tool.	It’s mentioned in the Integration Guide of dox_trace that the verifier from the code review tool is mandatory and must not be removed or skipped.
CF1	A complete stop of the control flow is usually no problem for a tool which runs offline and not on the target hardware. dox_trace is used for verifying changes on a code review tool. A stopped or terminated Sphinx build due to timeout must not lead to a merged commit.	It’s mentioned in the Integration Guide of dox_trace that the verifier from the code review tool must exit successfully, otherwise the commit must be rejected.
CF2	This is a very generic problem and can lead to random errors.	The likelihood is reduced to a minimum by intensive unit tests. To ensure that enough unit tests are written, the code coverage is 100%.

Main Workflow

This analysis is done on the Fig. 7 with the Use Cases in mind.

Element ID	Error ID	Specific Error Description	Measures	References
p1	PR1.1	Cache is not prepared properly which could lead to undefined behaviour.	If the cache is not prepared properly, subsequent read and write calls will result in exceptions due to missing data structures which means Sphinx is terminated with exit code != 0. The verifier executes a complete build to avoid problems with incremental builds.	Cache access is implicitly tested by almost every test case. Integration Guide
	PR1.2	The version is not determined correctly which may lead in using incompatible cache data.	This is only relevant if the extension is updated. It’s likely that an exception occurs due to incompatible cache data. The verifier executes a complete build to avoid problems with incremental builds. Tested by unit tests.	Integration Guide
	PR2	Callbacks or directives are not registered which means the extension is not active.	When trying to parse specifications, Sphinx will raise an exception due to unknown directives and terminate with exit code != 0.	*_spec.rb
p2	PR1.1	Files are loaded incorrectly or not loaded completely.	In most cases syntax and consistency checks within the loader will recognize the errors and Sphinx will terminate with exit code != 0. Users have to review the output. Tested by unit tests.	checks_spec.rb Integration Guide
	PR1.2	Wrong files are loaded.	In almost every case random files are neither syntactically correct nor consistent which will lead to loading errors. Users have to review the output.	Integration Guide
	PR2	If loading is skipped, no specifications are available for subsequent steps.	This is recognized by the user or latest by the reviewer in the code review tool because the HTML output and the Dim export will be empty.	Integration Guide
p3	PR1	Consistency checks are passed even with inconsistent data.	In most cases inconsistent data will lead to exceptions in further processing of the data, e.g. due to unresolved references. Users have to review the output. Tested by unit tests.	checks_spec.rb Integration Guide
	PR2	Consistency checks are not executed.	see p3/PR1	n/a
p4	PR1	HTML output is wrong.	Users have to review the output. Tested by unit tests.	*_spec.rb Integration Guide
	PR2	HTML output is missing or stored at wrong location.	Users have to review the output. Missing output is detected by the verifier. Tested by unit tests.	*_spec.rb Integration Guide
p5	PR1	Dim export is wrong.	Syntactically wrong Dim files are recognized by the verifier during the dim check. Tested by unit tests.	*_spec.rb Integration Guide
	PR2	Dim export is missing or stored at wrong location.	Users have to review the output. Recognized by the verifier during the dim check. Tested by unit tests.	*_spec.rb Integration Guide
p6	PR1	The exit code is set to a value != 0 instead of 0.	An exit code != 0 indicates an error. The code review tool will reject the commit. Tested by unit tests.	In almost every unit test the exit code is checked. Integration Guide
	PR2	The exit code is not set explicitly which means it can be != 0 instead of 0.	see p6/PR1	n/a
p7	PR1	The exit code is set to 0 instead of != 0.	Tested by unit tests.	In almost every unit test the exit code is checked.
	PR2	The exit code is not set explicitly which means it can be 0 instead of != 0.	see p7/PR1	n/a
s1, s8	DS1.1	Wrong specification data is loaded.	In most cases syntax and consistency checks within the loader will recognize the errors and Sphinx will terminate with exit code != 0. Users have to review the output. Tested by unit tests.	*_spec.rb Integration Guide
	DS1.2	Files do not exist in the file system.	If files do not exist, Sphinx will terminate with an exit code != 0.	Integration Guide
	DS2	n/a, only read access	n/a	n/a
s2	DS1	The cache is corrupted.	In most cases consistency checks will recognize the errors and Sphinx will terminate with exit code != 0. It is also likely that the Dim export will produce incorrect Dim files which is recognized by a dim check. Users have to review the output.	Integration Guide
	DS2	The cache is not updated.	If the cache is not prepared properly, subsequent read and write calls will result in exceptions due to missing data structures which means Sphinx is terminated with exit code != 0. The verifier executes a complete build to avoid problems with incremental builds.	Integration Guide
s3	DS1	n/a, only write access	n/a	n/a
	DS2	Existing HTML files are not updated.	see p4/PR2	n/a
s4	DS1.1	Dim export is missing or stored at wrong location.	see p5/PR1 and p5/PR2	n/a
	DS1.2	Properties file is not loaded.	Fallback values of all attributes are either empty or not_set, which means this is identified by manual review or automatic checks.	Integration Guide
	DS1.3	Other configuration parameters e.g. regarding backward compatibility are not as intended.	In most cases this will lead to a parsing error and Sphinx will terminate with exit code != 0. Users have to review the output.	Integration Guide
	DS2	n/a, only read access	n/a	n/a
s5	DS1	n/a, only write access	n/a	n/a
	DS2	Existing Dim files are not updated correctly.	see p5/PR1 and p5/PR2	n/a
s6	DS1	n/a, only write access	n/a	n/a
	DS2	Wrong exit code is used.	see p6/PR2 and p7/PR2	n/a
s7	DS1	n/a, only write access	n/a	n/a
	DS2	Error messages are wrong or not visible on the console.	The user might miss the information, but the exit code != 0 indicates that something went wrong. The verifier will reject the commit. Tested by unit tests.	*_spec.rb Integration Guide