DIFFERENCE BETWEEN MIS-IS-IT & EMBEDDED SYSTEMS
Interesting Post from SIMS Discussion Group
Author: Gary C.Smith (l975924)
Date: Jun. 17 11:19 AM 1997
I agree up to a point that an IS approach will support the Year 2000 needs for process control and embeded systems - at a 60,000' (ie. Assess/Plan/Do/Verify) level. We are very structured, strong on documentation, testing, etc. - just what the Y2K projects need. However - As you fly lower the, differences between these technologies become very apparent (my "big 6" differences are described below).
To date, I have been unable to locate anyone who is addressing the Embedded Testing issue at a detailed level - across a number of Web discussions. Most of these discussions originate from IS Fold who recognise the problem, and are prepared to raise the issue, and in some cases take ownership for them.
With due deference to the participants in this forum, what is missing is a groundswell from the Engineering and Process Control community who seem to me to be largely ignoring (or ignorant of) the severity of the problem. This is largely true of the suppliers as well. We need people with real experiance of the design and testing of Embedded systems to start to contibute - otherwise I don't expect to see much useful low level information.
Potentially worse is the assumption (and the related risks) that IS originated solutions and approaches which are appropriate for scanning Mainframe, UNIX Code, can also be used for assessing ladder and loop logic, intelligence burned into PROMs, and other areas that are seen in Process Control and Embedded systems.
Perhaps the only tools that we have (and will have) are a Robust methodology, detailed tracking, change management, risk assessment and internal certification. If that remains the case - we'll need to invent a process for each different piece of kit to be tested. ie. Lots of pain and no gain.
______________________________________________________________________
Embedded systems are different from the Formal IS applications in several ways:
A. Date Processing
Embedded and Process Control Systems tend to be real-time so they often do not store or use the year, in many cases they are purchased rather than built internally. This would suggest that a much lower percentage of applications will be affected than in the formal IS Area, and perhaps that where they are affected, the solution can be a "simple" upgrade.
B. Range of Technology
Embedded and Process Control Systems cover a range of technologies or
applications that is significantly greater than in the formal IS areas - and our ability to produce an accurate inventory is probably less, they are typically much closer to the production operation and are often mission critical.
C. Timing of Impact
Embedded and Process Control Systems are generally not impacted until
31st December 1999/1st January 2000. The Time horizons in many of IT/IS Applications are measured in days, weeks, years, so that in planning systems for example impact is seen several year BEFORE 1st January 2000. Many Financial institutions have been working on the issue since the late 1980's. This means that there is some experience that can be applied in the IT/IS areas. This is not true for Embedded and Process Control Systems.
D. Tools for Resolution
In the IT/IS arena, an increasing number of vendors have been pushing suites of tools that will assist in converting non-compliant code, primarily on Mainframe platforms, to be compliant. (Products such as COBOL have such an enormous inventory Worldwide that Vendors are prepared to invest in development of tools to aid resolution). In addition,there is a considerable selection of internal softwere dev `CASE' Tools that can be applied to the Year 2000 problem.
The range of technologies that is utilized for Embedded Systems and Process Controllers is enormous. Consequently vendors are not emerging with tools to "fix the problem", and are unlikely to do so.
E.. The Balance of Purchased vs. Internally developed technology/applications There is large legacy of internally developed software in the IT/IS arena. This is true to a lesser extent in the Process Control Systems where Ladder and Loop Logic and other applications are critical to the business, but where often application functionality is often provided by vendors and is configured rather than coded in order to be implemented.
For embedded systems there is a more even mix of internal and purchased technologies. Where systems have been purchased, suppliers will need to be contacted to determine Year 2000 compliance. This presents a host of issues about credability of their replies.
F. Testing Options
In the IT/IS areas, Test platforms generally exist and can be scheduled for Year 2000 Impact Assessment and testing without impacting the production environment until time is required for implementation.
For Embedded Systems in particular, and often for Process Control Systems there is not a spare system where we can turn the clock to 2000 to see what happens, (and in some cases if we had a spare - it wouldn't be obvious how to do this) so that the only option is to perform assessment testing during (often scarce) production downtime. |
