Recent IDA News and Events!

Integrated HW/SW Fault Tree - IDA has recently developed the methodology for generating Integrated Hardware/Software Fault-Trees. This new concept incorporates the software logic events implemented by a micro-controller and it’s respective embedded software with system hardware, and shows the relationships between events necessary to produce the undesirable top-level failure. In situations where embedded software controls the system, the interaction of the software logic with the hardware failures must be considered in order to discover all the events that can produce the top-level fault. Many times, as was demonstrated by the recently completed Integrated Fault Trees by IDA, hardware failures on the sensor side of the micro-controller and incorrect commands/status from other embedded processors generated failure events within the Fault Tree because of software logic interaction with the hardware. These failures would not have been detected or detailed in a hardware-only Fault Tree. The Integrated Fault Trees lead to some important software changes that increased the system’s fault-tolerance and provided a tool to the Reliability Department for assessing future changes.

Test Optimization Analysis - IDA has developed a method to assure that your product’s Test Program doesn’t become a demonstration of basic functions. An effective system Test Program requires in-depth knowledge of the system requirements as well as the "as-built" implementation of the requirements. Often the Test Engineer does not have the insight into all the interactions between system functions in the "as-built" configuration. IDA uses our Baseline Analysis Tools that represent your system implementation and your requirements to create products aimed at streamlining your Test Program. This new analysis is called a Test Optimization Analysis, or TOA. IDA using the TOA methodology, can maximize requirements coverage by testing and generate more efficient test cases and procedures. The best news is that a TOA can be added to a Sneak Analysis for a fraction of the cost!

Traceability Analysis "Waterfall" Diagram Matrix - When defining a system, requirements start with a high-level functional specification that eventually generates many lower-level hardware and software specifications. Each of the functional requirements ("parent requirements") within the high-level specs. have associated low-level requirements ("child" requirements) further describing the details of how the function is to be implemented. A requirements Traceability Analysis is performed to assure that all requirements are implemented into the system as either hardware, software or both. An effective Traceability Analysis also should show the hierarchy between requirements, any differences between the "parent-child" functionality and if any requirements are "orphaned" otherwise, having no parent requirements.

IDA has developed a new tool for representing all this information called a Waterfall Diagram Matrix. The Waterfall Diagram Matrix format graphically shows how each requirement is hierarchically related between the parents and the children and any differences or issues between the parent-child requirements within the function or other system functions - all in a single matrix. This graphical depiction provides the Systems Engineer a roadmap between system hardware and software specs, back to all the functional specifications that defined it and quickly indicates any orphaned requirements. The Waterfall Diagram Matrix also serves a second purpose when performing future system upgrades or changes. If any of the requirements change, the Waterfall Diagram Matrix can graphically indicate all the affected requirements above or below the change in hierarchy that may necessitate further review or re-design of the system. This tool is especially useful by both the Systems Engineering or the Quality Departments when considering the effects of upgrades and changes.

Software Sneak Analysis Used As A Static/Dynamic Code Analysis Tool - Static code analysis can identify unreachable code, infinite loops, initialization errors, code complexity, and output variable ranges that could generate a logic problem. Most of the static analysis techniques use an intermediate language interpreter that translates the computer language written by the programmer into a language used by the analysis tool. After the software code is translated into the intermediate language or IL, the IL is processed and reports are generated. These reports are anomalies detected in the IL that require further investigation by a software analyst to determine if a logic or control problem really exists in the actual code. The reports can be extensive and sometimes the IL translation multiplies the number of anomalies because of the particular syntax used when converting the original software code to IL. The anomalies are detected by using a pre-determined list of known problems based on the complexity, program paths, and logic executed within the software paths.

Dynamic analysis of the software code requires a more robust simulation of actual execution. Many of these tools are difficult to set up and execute while providing an incomplete simulation of hardware timing and interface characteristics. These tools also require an intermediate language interpreter to implement and experienced analysts to interpet the results. Since the tool is executing a simulation of the software, detected anomalies require further analysis by an experienced software analyst of the actual hardware and software to verify the results.

IDA's Software Sneak Analysis has been recently used to identify similar problems that can be detected by static and dynamic code analysis tools. IDA does not use an Intermediate Language translator in it's software tools, instead, IDA uses Software Network Trees and a Program Operation Diagram (POD). These tools are actual program code depicted graphically and topologically to assist in functional and logic analysis of the software. IDA has found that the translation of system software into an IL can become subjective in complex situations. The translation must be assisted by an experienced analyst to obtain a workable model acceptable to the Static/Dynamic Code Analysis software. This human-intervention in the IL process could intoduce of even cover-up an anomaly. Furthermore, when an anomaly is detected using IDA's method, the results require no further verification because IDA's tools are actual source code and system hardware.

IDA then cross-references all variables between the Network Trees to show every instruction where the variable is either referenced or modified (defined). IDA uses the cross references and tracks the software program flow using a POD that demonstrates the order of execution of the software in real time. With this proven methodology, IDA can uncover similar problems that static analysis discovers and also the dynamic, timing problems that may remain hidden by any other technique. IDA can also integrate in actual system hardware in the analysis, not a simulation, to uncover interface problems between the hardware and software.