The purpose of this article is to present an skeleton outline for a company’s Embedded Systems (ES)Y2K project. However, it is not the purpose of this article to imply that this outline is comprehensive and suitable for your business but to provide a basis for discussion and comparison between ES professionals and their management about their ES Y2K project.

In a related article Embedded Systems and Y2K on this Web site, I discuss Embedded Systems and Y2K. As I stated in that article "The typical company involved with manufacturing or processing as a core business activity probably utilizes ES safety and control systems. This typical company’s ES Y2K project and problem is potentially (and probably) the company’s largest exposure to the Y2K problem."

Therefore, it is very important that a company’s ES Y2K project outline encompasses at least the following elements:

• Boundaries
• Inventory
• Risk Assessment
• Testing
• Remediation
• Contingency Planning
• Change Management

I’ll expand on each of the preceding elements:

The first element of the project outline should be establishing ES Y2K project boundaries and assigning ES Y2K project responsibilities for each area. The tasks involved in the Boundaries element should include compiling a comprehensive list of personnel in your company that design, install, and maintain the ES used in all of the companies facilities. Representatives from each of these personnel groups should be involved with the company’s ES Y2K project. The list may contain personnel from Engineering, Maintenance , Operations, Building Management, Special Services(internal), Purchasing, Marketing, and Key Contractors. When dividing up responsibilities for the company’s ES project, it is important that all areas and company facilities are covered. This step should minimize "gray areas of responsibility".

A problem at the company’s office building with the fire detection system may prevent the company from using the office and may be potentially as serious as an ES Y2K problem at the company’s plant. Likewise, a problem with a key supplier or customer may be equally as serious.

The second element of the project outline should be Inventory. The purpose of the inventory should be to help identify suspect ES systems and components. The tasks involved in the inventory element should include compiling a comprehensive and accurate inventory of ES used in the companies facilities. An inventory strategy may be to inventory each system along with that system’s components used within the system. Utilizing this inventory strategy should make the next step, Risk Assessment, more manageable as risk rankings should only have to be performed at a system level.

This inventory task may be much more difficult than it first appears because of the following issues:

• ES may be used in remote, hard to access locations.
• ES may be hidden on these locations to prevent theft or vandalism.
• Personnel doing a physical inventory or inventory verification may not be familiar with the facility or the particular ES technology employed at the facility, or both.
• Personnel may transcribe model information incorrectly, for example mistaking a serial number or a revision number for the model number or vice-versa.
• Getting correct model and version numbers of ES may require a process shutdown and disassembly of the ES.
• Current inventories may only include high level info not detailed enough to identify suspect ES components.
• Legacy , older ES may be undocumented in current inventories.
• Systems may have been installed and not reported to the employee(s) responsible for maintaining the inventory.
• There may be no inventory of the ES at the facility.

The third element of the project outline should be Risk Assessment. The tasks involved in the Risk Assessment element may include assigning a risk ranking factor to each inventory record of ES used in the companies facilities. A company may want to utilize internal (or external) Operations and Engineering "Subject Matter Experts" to assign or review assigned risk rankings.

A strategy may be to assign a 1-5 risk ranking score (where 5=High Risk or Mission Critical systems and 1= non-critical systems)to each system and not to each component used within the system. In many cases without detailed knowledge of the system design, assigning accurate risk values to components would be difficult, if not impossible.

Additionally, as a risk management strategy, a 5-1 "knowledge factor" score may also be applied to each system. The "knowledge factor" score may be 5 for unknown Y2K compliance status down to a 1 for systems that have no date/time functionality. The total risk for any system at any time is the current product of the two scores. Employing this method should allow a company to measure its total risk exposure and also measure how this risk exposure is reduced as research, testing , and remediation phases of the project are executed.

The fourth element of the project outline should be Testing. This element is closely aligned with the Inventory and Risk Assessment elements as those elements should determine what systems may be necessary to test.

The testing element may encompass the following items:

• Researching system and component technical and Y2K compliance information
• Determine what systems and/or components are necessary to test
• Developing test plans
• Scheduling the tests
• Documenting the tests
• Using test results to identify critical systems for remediation and contingency plans

A company may chose not to test but to apply manufacturers or third party test results to their systems. A company may also chose to independently verify the manufacturers or third party test results and claims by testing their systems themselves.

A few items to consider when testing:

• Test planning may take as long as the actual testing
• Consistent and complete documentation of the test plan and test results is very important
• In situ system or component testing requires a higher, more comprehensive level of test planning than bench testing
• If others in your company plan on utilizing your test results be sure to test all of the systems or components functionality
• Don’t forget the user code(such as RLL in PLCs) that may be present in the ES- it may be not compliant.
• Also don’t forget to test the manufacturers support programs that are used to program or configure the ES
• Look for a widely accepted test procedure to follow when testing your ES- check our links to industry organizations Y2K pages.

If you decide to test, testing will be a significant portion of your Y2K ES project, maybe the most resource intensive portion.

The fifth element of the project outline should be Remediation. Remediation may involve fixing Y2K related problems, replacing non Y2K compliant systems or components, or taking such systems out of service. The tasks involved in the Remediation element should include reviewing the test results for systems or components that are not compliant for systems with a high risk or mission critical risk ranking. A remediation project should give priority to these high risk mission critical non-compliant systems. A strategy may be considered where the Y2K project team identifies systems or components for remediation and another organization executes the actual project.

The sixth element of the project outline should be Contingency Planning. Contingency Planning may involve developing plans to safely deal with non Y2K compliant systems or components. Also contingency plans may be developed for systems deemed to be Y2K compliant. The contingency plan should identify actions to take in the event the system or component fails. Many times , these contingency plans already exist. However, Y2K problem contingency plans should consider the possibility of simultaneous ES failures along with possible infrastructure (electricity, water, waste water, etc. ) failures.

The seventh element of the project outline should be Change Management. Change Management may involve a process to ensure that if new ESs are added or changed during the course of your ES Y2K project that these additions or changes are captured in the inventory and included in the Y2K project. Many companies already have Management of Change programs in place. It may be possible to leverage off of one of these existing programs to ensure changes are included in the project.

In summary, the success of your company’s ES Y2K project may be crucial to the survival of your business. Make sure ES professionals assigned to your project are give adequate resources and management support in order for them to successfully execute the project which should reduce your companies risk to an manageable level.

Again, I would like to state that the above hypothetical ES Y2K project outline is just that and is not meant to be a process that is comprehensive and suitable for your company.