Software issues

Ensuring the integrity of process controls involves both hardware issues, software issues, and human issues. Of these, the hardware issues are usually the easiest to assess and the software issues the most difficult. 

For any application, the software used for model deployment is quite different than the software used for model development. This is because deployment software has a very different function, and thus very different reqnirements, than development software. Whereas development software requires flexibility and nser-friendliness, deployment software requires long-term stability, reliability, and accessibility to critical on-line data. The following are questions that reflect some conunon deployment software issues in a PAT project ... 

For help with our computers and computer software issues we are indebted to A. J., to Saad, and to Darrell. 

Embedded Software constitutes a very specific and critical part of embedded systems. It provides new capabilities to HW transducers ( defines physical behaviour of a complex non-linear device ), because of its potential criticality we need HW/SW co-design, and issues like dependability, low power, timeliness are becoming software issues with all the consequences. We need dependable system architectures to cope with the potential risks, including safety as well as security requirements and counter measures. Be aware, that security aspects are often neglected by safety engineers ... 

The data on lot 2 of day 9 showed a wide process variation (endpoint time increase) from the previous set of data. An analysis of the CMP status log with the endpoint data indicated that slurry was not being pumped to the pads on the tool. The problem was not detected until two hours after it occurred. The root cause was traced to software issues in the slurry distribution system. Note Real-time endpoint control with set specification limits would have resulted in a warning at the time of excursion. Observation over a three day period examining two lots per day and three wafers from each lot (Figure 4), showed that half of the total variation is explained by lot differences. Wafer-wafer variation within a lot is significantly smaller than between lots. 

We then moved to troubleshooting software issues. Starting with DOS and moving to Windows, we discussed common configuration files and techniques that can be used to test their validity. 

We acknoivledge the use of the computer assets of (he Major Shared Resource Center of the U.S. Army Research Laboratory and ihe advice of Dr. John Peumann of Duke University on some software issues. 

An early assumption that the problem was due to a particular hardware fault (therefore largely ignoring the underlying software issues) despite there being little evidence to support this. 

NOTE Software issues apply only to SIS using PE technology. 

There are three types of FMEA/FMECA functional FMEA/FMECA, DFMEA/ DFMECA, and PFMEA/PFMECA. Apart from these there are two other types of FMEA service FMEA and SWFMEA. In service FMEA the focus is on service issues. SWFMEA (discussed separately in later clauses) focuses on software issues. Functional FMEA/FMECA is also known as concept FMEA/FMECA or system FMEA/ FMECA. Some literature shows two types of FMEA/FMECA in the sense that one is functional and other is hardware FMEA/FMECA (where both PFMEA/PFMECA and DFMEA/DFMECA are considered under hardware FMEA/FMECA). These different types are a result of changes in analysis pattern and assessment, but the basic concepts/approaches are the same. 

Systematic faults occur due a combination of conditions resulting in a reproducible failure of the system, and are most often attributable to software issues in programmable safety systems. This failure may be a result of some error in design, operation or production process, installation and/or maintenance. Improper implementation of MOC at any stage could be responsible for systematic failure also. Device manufacturing errors can be addressed by diversity this increases the SIF complexity. Diversity can be applied to sensor, I/O technologies, control and software platforms, and even product development teams. Incorrect specification, implementation. 

The main issue here is that for any programmable system, both hardware and software aspects are equally important. International standards for PE take into consideration hoth hardware and software. In contrast to previous discussion, now the discussions hoth hardware and software issues related to safety system and SIL will be focused on to show both their importance and their interactions. Another important issue is when any PE safety-related system needs to implement both safety and nonsafety functions, then hardware and software shall be developed and treated as safety related unless there is enough independence between the safety and nonsafety functions, and it can demonstrate that ... 

An ideal system is web-based to avoid software issues on supplier computers. 

---