FMEA Step 5 — Effects Tab

Effects

The FMEA analysts assume the failure mode exists, and analyze what happens when it transpires. Requs AI Predict does the time-consuming work of determining which failure modes are relevant, using the Common Defect Enumeration (CDE) to keep the analysis focused on what’s most likely to go wrong — a functional approach rather than an ineffective black-box one.

Before You Start

Three steps before assessing effects

Go to the Survey tab and complete the “Product information” questions — this determines which CDEs aren’t relevant to your system (e.g. machine learning failure modes don’t apply if your system has no machine learning). If a failure mode looks irrelevant, revisit Product Information.
Go to the Survey tab and complete the “Failure Modes” subtab as best you can.
Review the import template for every input flagged in column J, “Used by software FMEA” — these affect likelihood and relevance. The testing-related questions are particularly important for likelihood.

CDE Structure

How the Common Defect Enumeration is built

Each CDE is a unique identifier for a failure mode that has caused at least one real-world failure. See the full Common Defect Enumeration on the DAU R&M Community of Practice website.

Enumeration syntax “Level”-“Failure mode”-“Root cause index”-“Description”. Example: TL-SM-1 — Prohibited state transitions are executed. This is a top-level state-management failure mode; 1 is the first root cause on the state-management list.

Level

Meaning

Top level

Capability level (one feature or subsystem)

Failure mode

Meaning

SM — State management

The software is unable to maintain state, executes incorrect transitions, dead states, etc.

EH — Error handling

The software is unable to identify and handle known system faults.

T — Timing

The software executes the right thing too early or too late.

SE — Sequencing

The software executes the right thing in the wrong order.

DD — Data definition

Wrong or incompatible definitions of size, type, format, unit of measure, scale, etc.

PR — Processing

The software is unable to handle peak loading, extended duration, file I/O, etc.

F — Functionality

The software does the wrong thing perfectly — it doesn’t meet the basic reason for its existence. Example: software built to speed baggage delivery to aircraft that instead slowed it down.

A — Algorithm

Even the simplest algorithm — dividing two numbers — commonly fails when a denominator near zero isn’t handled.

U — Usability

Usability faults caused by the software that have led to mission faults.

ML — Machine learning

Faults due to data collection, labeling, and modeling.

CDE Reference

The full failure mode list

An excerpt from the CDE on the DAU R&M CoP website — the description, discussion/example, and typical applicability of each failure mode. Requs AI Predict determines which CDEs are relevant from your Product Information answers in the Survey tab.

Failure Mode ID

Description

Discussion / example

Applicability

TL-SM-1

Prohibited state transitions are executed

Prohibited transitions are what lead to irrecoverable events such as inadvertent launches

This is applicable for virtually all software intensive systems

TL-SM-2

Valid transitions are allowed under invalid conditions (This is a conditional prohibited state transition)

A transition made with the wrong criteria reduces to a prohibited transition which is what lead to irrecoverable events such as inadvertent launches

This is applicable for virtually all software intensive systems

TL-SM-3

States are stuck (dead state. This is most common when an error state is entered but isn't reset when the error is corrected.)

Systems often get stuck when they enter an error state, the error is fixed and then the user has to reboot to clear the fault.

This is applicable for virtually all software intensive systems

TL-SM-4

The software is unstable after an unexpected loss of power while in a particular state

Forgetting to design for an unexpected power loss is a common oversight. From a software perspective the failure happens when the power is restored. The software can be in the wrong state or unpredictable state.

This is applicable for virtually all software intensive systems

TL- SM - 5

The software is unstable after an unexpected user abort while in a particular state

Software engineers often fail to consider all of the possible states that a user can execute an abort. Sometimes it may be required to disable the abort. (Ex: when upgrading an operating system the user is not allowed to reboot). Depending on the state in which the user aborts, there could be dramatically different required behavior.

This is applicable for any system with a user interface

TL-SM-6

The software is missing a fault or safe state

if a weapon is failed it needs to be in a reduced capability state.

This is applicable for virtually all software intensive systems

TL-SM-7

The software is missing a transition to a fault or safe state

In addition to having a fault/safe state there also needs to be a transition to the fault or safe state

This is applicable for virtually all software intensive systems

TL-SM-8

The behavior of the fault or safe state is inappropriate for the system mission

Once the software enters the safe or fault state it must execute the correct behavior. In some cases that means doing nothing. In other cases it might mean attempting to heal the fault.

This is applicable for virtually all software intensive systems

TL-SM-9

The software as a whole is missing a state

This is a general version of TL-SM-6. The software might be missing any state. This can happen if there are many states.

This is applicable for virtually all software intensive systems

TL-SM-10

The software as a whole is missing a state transition

This is a general version of TL-SM-7. The software might be missing any state transition This can happen if there are many states and transitions.

This is applicable for virtually all software intensive systems

TL-SM-11

The software commits a prohibited transition to different feature (a different state machine) within the software

This is similar to TL-SM-1 except that the software allows a prohibited transition to a different feature within the software.

This is applicable for virtually all software intensive systems

TL-SM-12

The software accommodates a prohibited transition from a different software feature (a different state machine)

This is similar to TL-SM-11 except that the software allows a prohibited transition from a different feature within the software.

This is applicable for virtually all software intensive systems

TL-EH-1

Hardware faults aren't detected

Whether the software requirements say so or not, it's the job of the software to detect any and all hardware faults. Hardware faults includes sensors, weapon hardware, etc.

This is applicable for virtually all software intensive systems

TL-EH-2

Hardware faults are detected but aren't appropriately handled

Detecting hardware faults is only half of what's needed. The software must execute the correct behavior based on the type of hardware fault. One common fault is for the software to "reboot" when the hardware fails. This is rarely the right behavior.

This is applicable for virtually all software intensive systems

TL-EH-3

Communication faults aren't detected

The software needs to detect a loss of communication regardless of whether the software requirements say so.

This is applicable for virtually all software intensive systems

TL-EH-4

Communication faults are detected but aren't appropriately handled

Detecting communication faults is only half of what's needed. The software must execute the correct behavior once the fault is detected. One common fault is for the software to "reboot" when there is a comm failure. This is rarely the right behavior.

This is applicable for virtually all software intensive systems

TL-EH-5

Computational faults aren't detected

Computational faults are when software computations don't consider all possible inputs or outputs. One example is the "NaN" - not a number fault when the software doesn't consider data is that is not numeric. These need to be detected whether the specification says so or not.

This is applicable for virtually all software intensive systems. It is most relevant for any software that is performing any calculations.

TL-EH-6

Computational faults are detected and aren't appropriately handled

Detecting computational faults is only half of what's needed. The software must execute the correct behavior once the fault is detected. One common fault is for the software to "reboot" when there is a computational failure. This is rarely the right behavior.

This is applicable for virtually all software intensive systems. It is most relevant for any software that is performing any calculations.

TL-EH-7

Power faults (i.e. wrong voltages) aren't detected

Power faults are when the software allows an out of range voltage or current or doesn't allow an in range voltage or current.

This is applicable for any system that has specific power up requirements.

TL-EH-8

Power faults (i.e. wrong voltages) are detected but aren't appropriately handled

Sometimes the software engineers may design a one size fits all for voltage faults such as endless loops that wait for the voltages to converge or prematurely declaring a weapon NMC.

This is applicable for any system that has specific power up requirements.

TL-EH-9

Battery depletion isn't detected prior to depletion

Detection/monitoring of battery depletion may be critical

This is applicable for any battery powered system

TL-EH-10

Battery depletion is detected but aren't appropriately handled

Detection/monitoring of battery depletion may be critical

This is applicable for any battery powered system

TL-EH-11

CRC faults aren't detected

Detection of Cyclic Redundancy Check ensures that there isn't noise in transmission.

This is applicable for most real time systems. Some systems need a CRC check and don't have one.

TL-EH-12

CRC faults are detected but not appropriately handled

Even if a CRC fault is detected it many be handled inappropriately

This is applicable for most real time systems. Some systems need a CRC check and don't have one.

TL-EH-13

File I/O faults aren't detected

File I/O faults include files not found, files can't open, files read error, file write error, files building up on a computer drive.

This is applicable for any software that interfaces with any files such as a database, ini files, text files, etc. Data logging for example writes to a file.

TL-EH-14

File I/O faults are detected but not appropriately handled

Detecting an I/O fault is only half of what's needed. Appropriate recovery is the other half. Rebooting or "one size fits all" error recovery are rarely appropriate.

This is applicable for any software that interfaces with any files such as a database, ini files, text files, etc. Data logging for example writes to a file.

TL-EH-15

Multiple simultaneous faults aren't detected

Software engineers often fail to consider that more than one fault can occur at about the same time. Consequently the first failure or last failure may not be recorded.

This is applicable for virtually any software system

TL-EH-16

Multiple simultaneous faults are detected but not appropriately handled

Detecting multiple faults is half of what's required. Properly handling multiple concurrent faults is the other half. Examples of improper handling include reporting of the less important fault before the more important fault, addressing one fault at a time even though the concurrent faults might be related.

This is applicable for virtually any software system

TL-EH-17

Multiple sequential faults aren't detected

Software engineers often fail to consider that more than one fault can occur in a sequence. Consequently the first failure or last failure may not be recorded.

This is applicable for virtually any software system

TL-EH-18

Multiple sequential faults are detected but not appropriately handled

Detecting multiple faults is half of what's required. Properly handling multiple sequential faults is the other half. Examples of improper handling include reporting of the less important fault before the more important fault, hiding the faults until the fault first detected is recovered from, etc.

This is applicable for virtually any software system

TL-EH-19

BIT software returns a false negative

A false negative BIT result can happen if 1) BIT results are reversed 2) if early BIT failures are overwritten by later BIT passes or 3) BIT results are improperly ANDed instead of ORed or 4) the software proceeds to the next BIT test when it should stop at the first BIT failure.

Applicable for any software that has Power On Self Test or Bit InTest or Continuous BIT or Periodic BIT

TL-EH-20

BIT software returns a false positive

A false positive BIT result can happen if 1) There was previously a failed BIT result that wasn't cleared from memory or 2) BIT results are reversed.

Applicable for any software that has Power On Self Test or Bit InTest or Continuous BIT or Periodic BIT

TL-EH-21

Software is unable to handle known user input errors

Humans will with 100% input incorrect data. Software engineers often assume otherwise.

This is applicable for any software with a user interface

TL-EH-22

The software does not clear out faults that have been resolved

When faults are resolved they need to be marked so that the user can focus only on the unresolved faults. Software engineers often forget to clear resolved faults from the user interface.

This is applicable for all software systems

TL-EH-23

The software is overly sensitive to faults

This happens when the criteria for the fault doesn't have any buffer for determining the fault. A commercial example - if a person pays their mortgage and is one penny short but the software sends them to foreclosure immediately. Another example is the software fails to wait for a short period of time to ensure that the fault isn't transient. Refer to Apollo 11 landing in which the software asserted a fault when the problem was temporary.

This is applicable for all software systems

TL-EH-24

The software fails to detect when communication has resumed after a communications loss

Detecting loss of communication is important. But detecting when the communication has been restored is also important. In commercial applications it's a common event to have to reboot for the software to recognize that communication is restored.

This is applicable for all software systems

TL-EH-25

System is unable to handle removal of external storage device

If there is an external storage device there is always the possibility that the user will remove it in operation. If the software isn't monitoring whether the device is still connected that can cause a range of problems.

Any system with a removable storage device such as removable drives, etc.

TL-EH-26

Data logging is unable to handle failing of external storage device

Any system with a removable storage device such as removable drives, etc.

TL-EH-27

Software fails to detect low or no consumable levels

Consumables can include fuel, oil, ink, etc.

Any system with a consumable such as fuel, oil, ink, etc.

TL-EH-28

The software fails to check the state of the system before submitting a job that could be too big for the hardware to support

Ex: A user wants to send a 5000 page document to a printer. The printer software cannot accommodate a job that big. The user should be advised that the job is too big for the system to handle.

Almost any system

TL-EH-29

The software fails to detect that another software component that is not or has stopped executing

Ex: There are dozens of software applications in the system. One of them stops working and the others don't detect this.

Virtually every system (nearly all modern systems have more than one software component).

TL-EH-30

The software fails to properly handle and recover from another software component that is not or has stopped executing

Ex: The software detects that another software component is not executing but it does the wrong thing such as shut down.

Virtually every system (nearly all modern systems have more than one software component).

TL-FC-1

A required feature is missing

Today's systems are large and complex. It's not unusual for system requirements to be inadvertently left out of the software requirements. Software requirements are traced to system requirements but rarely are system requirements traced downwards to software requirements. Ex: The Cryosat-1 failed because the command for the main engine cutoff was missing.

Applicable for any software. But particularly relevant for systems that are so large that a required feature might be overlooked.

TL-FC-2

A crucially important detail is missing from the entire set of specifications

Overly general requirements is a common problem in every industry. The software engineers have too many options for implementing the requirements and hence may guess at a solution that isn't what the customer wants.

All software systems

TL-FC-3

The software cannot accommodate a full range of input trajectories

An input trajectory is not just the range of inputs but the time sequence of inputs. Ex: A fin on a missile must move from one angular position to another. The trajectories are the sequence of movements over the flight.

All software systems

TL-FC-4

The software is unable to operate with a change in mission distance or time

Ex: A system used to have a mission time of X hours and now has a mission time of X+Y hours. The software may not work as required with the new mission time.

Any system that has recently been modified to have a change in mission time, distance or payload

TL-FC-5

The software fails to achieve it's required goal.

Ex: The Denver Airport software had exactly one goal - to reduce the time it takes to get the bags onto the aircraft. The software actually caused the time to get the bags on the aircraft to be longer than not using any software at all. That's because the software assumed that the bags would be perfectly placed onto the luggage system and would never fall off the luggage system. The software requirements should have had one performance requirement to measure the time it takes for the bags to get to the aircraft with normal operation by imperfect humans.

All software systems

TL-FC-6

There is no data logging and there should be

Mission critical systems need data logging for fault isolation and support of the field.

Any mission critical software system

TL-FC-7

BIT software interferes with operational execution

BIT software can and will effect operations. If it is executed at the wrong time or wrong phase it can cause the software to fail to perform it's job.

Applicable for any software that has Power On Self Test or Bit InTest or Continuous BIT or Periodic BIT

TL-PR- 1

Software loses accuracy after extended duration with no reboot

Software doesn't wear out but it can experience a degradation in performance due to timing and data inaccuracies that accumulate.

Any system that is on for more than a few minutes or hours without rebooting

TL-PR- 2

Software is unable to execute after extended duration with no reboot

Software doesn't wear out but it can experience a degradation in performance due to memory faults.

Any system that is on for more than a few minutes or hours without rebooting

TL-PR- 3

Software is unable to execute due to build up of files

The NASA spirit rover is just one example of what happens when files such as log files accumulate and then cause the system to run out of disk space in the middle of a mission.

Any system that has any files that grow in size. Log files, database files, video files, audio files, etc.

TL-PR- 4

Data logging files are overwritten before they can be read by a user

Rolling over files is a mitigation for failure mode PR-3. Unfortunately sometimes the rollover may be too frequent and overwrite data before it can be read or used by the user.

Any system that has a data logging feature. This could include systems with video or audio recording.

TL-PR-5

Software degrades or stops working with maximum concurrent users

This failure mode has effected many commercial systems because software engineers neglect to design the system for maximum concurrent users.

Any system that has multiple concurrent users

TL-PR-6

Software degrades with many rapid operations

Example of rapid operations: A driverless vehicle starts and stops, starts and stops, starts and stops. Example 2: A weapon handles engagements in rapid succession

Any software system

TL-PR-7

Software degrades with simultaneous threats, targets, objects, inputs or requests

Example: An IFF can identify one threat at a time but not more than one at the same time

Any system that is doing threat detection, target tracking, image recognition

TL-PR-8

Software degrades with different threats, targets, objects, inputs, requests

Example: An IFF can identify multiple concurrent threats but not when they are of different types

Any system that is doing threat detection, target tracking, image recognition

TL-T-1

Initialization time is too long to accommodate uptime requirements

Example: A system must be up for 23 hours per day. However, the software takes 45 minutes to initialize and 30 minutes to set up. The system must be serviced once per day so it is guaranteed to not make uptime requirements.

Any software system

TL-T-2

The combined total of the restart times is too long to accommodate uptime requirements

Example: A system must be up for 22 hours per day for a 4 day mission. It doesn't need servicing during the 4 day mission. However, the software takes 45 minutes to initialize and 30 minutes to set up every time it reboots. If the software has to reboot more than once per day the availability won't be met.

Any software system

TL-T-3

Any manual action takes too long to accommodate the uptime requirements

Example: A system must be up for 23 hours per day. The user must set up the system after it initializes which takes 45 minutes. They are unable to do that within 15 minutes.

Any software system with an end user

TL-T-4

The time to safely shutdown the software after a mission exceeds the time required for required mission uptime

Example: A system has a 4 day mission and has timing requirements for transport between missions. The software must be shut down properly in order to work for the next mission. The shutdown time takes longer than the transport time allows.

Any software system

TL-T-5

Watchdog timers/heartbeats are missing

This is required for safety critical software and is all important for mission critical software

Any software system can have a WDT. The systems that have mission critical timing requirements typically need this.

TL-T-6

Schedulability exceeds required maximum

If the schedulability requirements aren't met, critical commands could get dropped

Any multi-threaded software

TL-T-7

Continuous monitoring is too frequent

If the monitoring is too frequent it will interrupt normal operations

Any software system

TL-T-8

Continuous monitoring is not frequent enough

If the monitoring isn't frequent enough it won't detect critical faults

Any software system

TL-U-1

Software assumes that the user is always looking the user interface

Ex: The software controlling a CT scan generates critical warnings on the display when the caregiver is helping the patient get into the CT scan.

Any software with a user interface

TL-U-2

The user interface has a paradigm that doesn't fit with generation of users using the system

Ex: Warfighters are largely generation Z and millennials. However the software interface was written by baby boomers for baby boomers. The warfighters are expecting to be able to pinch and zoom. The software crashes when they try to do that.

Any software with a user interface

TL-U-3

The software requires the user to handle faults when in fact the faults cannot be fixed by the user

The software should only require the user to address faults that they have the capability to address. Users cannot fix algorithm or data faults for example. They can fix hardware that's faulted.

Any software with a user interface

TL-U-4

The software floods the user with too many concurrent error messages

The software should attempt to combine or pool related error messages so that the user isn't flooded. Ex: An import file has 50 rows of data with the same data entry problem. Instead of displaying the same message 50 times, generate one message that end of import showing all rows with bad data.

Any software with a user interface

TL-U-5

The software fails to identify the urgency of the error message

If non essential error message are mixed with essential error messages the user may ignore all of them

Any software with a user interface

TL-U-6

The software has text entries when other simpler structures such as pull down menus suffice

Text entries are problematic because the inputs have to be checked for length of input, type of inputs, null entries, special characters, etc. These should be reserved only for input fields that can't be replaced with radio buttons or pulldown menus. Ex: Your name and address require a text entry. A pulldown menu is best for your state.

Any software with a user interface

TL-U-7

The software allows data overruns (i.e. The user pressing the enter key many times in a rows)

This is a race condition started by the user. This type of race condition has been associated with serious software failures.

Any software with a user interface

TL-U-8

The software allows the user to type faster than the input can be recorded

This can lead to undetected loss of information.

Any software with a user interface

TL-U-9

The software fails to provide positive feedback when a mission critical function is executed

Ex: Equipment that provides radiation therapy needs to be able to advise the practitioner (who is in a different room during the therapy) if the radiation was emitted as per the required prescription

Any software with a user interface

TL-U-10

The software fails to advise the user of an irreversible event

Examples include deleting files, starting a launch sequence, etc.

Any software with a user interface

TL-U-11

The user repeatedly makes bad requests

The user overloads the system with bad requests

Any software with a user interface

TL-DD-1

High level mismatches of unit of measure (i.e. metric/English) among software LRUs.

High level means that entire LRUs are written in one unit or the other (See the Mars Climate Orbiter). Entire LRUs were written in English when Metric was required for all LRUS. This isn't noticeable when examining a single LRU.

Any data interface that represents a unit of measure that can be either metric or English

TL-DD-2

High level mismatches of unit of measure (i.e. radians/degrees) among software LRUs.

High level means entire LRUs are using radians while others are using degrees. This isn't noticeable when examining individual LRUS. One must review the units across the LRUS to notice the conflict.

Any data interface that represents unit of measure of radians or degrees

TL-DD-3

High level mismatches of unit of measure (i.e. Clockwise versus counter clockwise) among software LRUs.

High level means entire LRUs are using CW while other LRUS are using CCW. This isn't noticeable when examining individual LRUS. One

Any data interface that represents rotation of clockwise or counterclockwise

TL-DD-4

High level mismatches of unit of measure (i.e. nautical miles versus miles) among software LRUs

High level means entire LRUs are using nautical miles while other LRUS are using miles. This isn't noticeable when examining individual LRUS.

Any data interface that represents miles or nautical miles

TL-DD-5

High level mismatches of scale (i.e. sec/msec) among software LRUs

High level means data across software LRUs has the wrong scale. If there is a mismatch of scale the algorithms can be off by a significant amount. During LRU testing the fault might not be visible. Once LRUs with different scaling are integrated this could cause a serious interface fault.

Any data interface that can be represented in more than one scale

TL-DD-6

High level mismatches of size (i.e. number of bits) among software LRUs

High level means data across software LRUs has the wrong size. If there is a mismatch of data sizes there could be overflows or underflows. During LRU testing the fault might not be visible. Once LRUs with different scaling are integrated this could cause a serious interface fault.

All data interfaces

TL-DD-7

High level mismatches of type (i.e. string, integer, float) among software LRUs

High level means data across software LRUs has the wrong type. If there is a mismatch of data types the result can be unpredictable. During LRU testing the fault might not be visible. Once the LRUS with different data types are integrated this could cause a serious interface fault.

All data interfaces

TL-DD-8

The software fails to detect data that is corrupt

Corrupt data isn't considered at all by the software . (i.e. this can be confirmed by searching through all specifications for the word "corrupt")

All data interfaces

TL-DD-9

The software fails to detect missing data

Missing data isn't considered at all by the software

All data interfaces

TL-DD-10

The software fails to detect shifted data

Shifted data is when a data table is inadvertently modified to be offset. Usually this is an offset by 1. This is caused by problems with write operations that are interrupted while writing.

Any data interface that is arranged in a fixed order

SL-SE-1

The top level sequence identifies the steps in an operation but fails to identify if order is relevant

Quite often top level sequence diagrams or flow diagrams neglect to point out if the order listed is mandatory.

Any software but particularly the software functions that must conduct an operation in a specific order

SL-SE-2

The top level sequence lists steps but has the order incorrect

The top level diagrams may show the order incorrectly

Any software but particularly the software functions that must conduct an operation in a specific order

TL-A- 1

Software is unable to handle crossing over international date line from east to west (i.e. reboots or fails to operate when time goes backwards)

Navigational faults occur when a real time clock is used AND time goes to a previous day abruptly. Software engineers often blindly write code for error handling without considering that there is a legitimate case in which the date can go backwards. This can apply to any system that is physically capable of crossing over the IDL. The IDL is entirely in water. Not all vehicles are able to cross the IDL.

Any software system with a real time clock that is capable of traveling over the international date line or can travel inside a system traveling over the IDL.

TL-A- 2

Software is unable to handle crossing over international date line from west to east (i.e. reboots or fails to operate when time goes forward)

Navigational faults occur when a real time clock is used AND time goes forward abruptly. This can apply to any system that is physically capable of crossing over the IDL. The IDL is entirely in water. Not all vehicles are able to cross the IDL. This fault is not as likely as the A-1 fault because transitioning forward to the next day is something that is typically considered by software engineers (i.e. flying or driving past midnight). It's the transition to an earlier day that is often overlooked.

Any software system with a real time clock that is capable of traveling over the international date line or can travel inside a system traveling over the IDL.

TL-A- 3

Software is unable to handle crossing over equator from south to north

This can cause navigational problems if the software isn't expecting a sudden change in the hemisphere.

Any software system with guidance/navigation that is capable of traveling over the equator or can travel inside a system traveling over the equator.

TL-A- 4

Software is unable to handle crossing over equator from north to south

This can cause navigational problems if the software isn't expecting a sudden change in the hemisphere.

Any software system with guidance/navigation that is capable of traveling over the equator or can travel inside a system traveling over the equator.

TL-A- 5

Software is unable to handle crossing over north pole

This can cause navigational problems if the software isn't expecting a sudden change in the hemisphere or extreme longitude coordinates. Software engineers also often assume (incorrectly) that vehicles cannot or won't go over the poles.

Any software system with guidance/navigation that is capable of traveling over the northpole or can travel inside a system traveling over the northpole.

TL-A- 6

Software is unable to handle crossing over south pole

Any software system with guidance/navigation that is capable of traveling over the southpole or can travel inside a system traveling over the southpole.

TL-A- 7

Software is unable to handle crossing over any international line with 2 different units of measure.

This can cause problems with sensors and refueling. Example: ML software reads speed limits in English after crossing from US to Canada and adjusts the speed incorrectly. Example 2: An aircraft designed in US stops for gas in Canada and gets 20 liters of gas instead of 20 gallons of gas.

Any software system that is capable of traveling over an international date line between two countries that have conflicting units of measure.

TL-A-8

Algorithm fails to converge

This can happen with regression models

Any software. This is particularly relevant for any software with algorithms that performing approximations.

TL-A-9

Sample rate is insufficient

Signal frequencies can overlap if the sampling rate is too low

Any software. This is particularly relevant for any software with algorithms that performing approximations.

TL-ML-1

Population sampling errors

Population sampling errors are when the data is not representative of the population