C&I engineering tools: Part 2 - Compliance and lifecycle costs
March 2009, SCADA/HMI
Each of us has a responsibility to ensure that our own companies or employers survive and prosper in the present challenging economic environment.
In Part 1 of this article we looked at collaboration and standards. Part 2 looks at resources to improve compliance and to manage lifecycle costs in automation and control: two recurring themes of the MMP ’08 conference.
Compliance and traceability
The requirement for manufacturers to comply with increasing volumes of national and international governmental legislation, quality management standards and industry regulations is resulting in significant operational burdens. Legislation may apply to financial data, responsible environmental behaviour, traceability and recall, security, data security and a host of other areas.
In the global context manufacturers or utilities may be obliged to comply with regulations like FDA Title 21 CFR Part 11, the Sarbanes-Oxley Act, EU Data Protection Directive and NERC CIP 002-009 Cyber Security Standards. Others may need to comply with ISO9000 series standards.
Failure to comply with regulations increases an organisation’s risk since it may result in direct financial loss, closure or penalties.
Impact on C&I
So how does this impact automation engineers? Compliance and traceability data need to be captured as close to realtime and in as automated a manner as possible. The dual aspects of compliance and traceability require data collection in realtime so that alerts can be raised and immediate action taken where data indicates non-compliance. For example, in pharmaceutical manufacturing operations where backward and forward traceability is mandatory for recall it is less costly to react to the fact that raw material lot number data is missing before mixing, than afterwards, when it may be necessary to scrap an entire batch of finished product.
Generally it is the automation systems in a plant that are able to provide the necessary compliance data and flag non-compliance early enough to remedy at least cost or zero cost.
A recent study² by the Aberdeen Group indicated that compared to lesser performers:
* Best-In-Class organisations had greater realtime visibility into the status of all processes from order to cash.
* Three times as many Best-In-Class organisations had non-conformance alerts linking back to ERP to flag potential schedule interruptions.
* Twice as many Best-In-Class organisations were able to achieve mock or real recalls in the time required by regulatory bodies.
However, the study reported that even Best-In-Class have some way to go, concluding that they could further:
* Extend interoperability to the shop floor: “Although 44% of Best-In-Class are able to identify variances in production in near real-time, only 31% have non-conformance alerting back to ERP.”
* Implement event management to monitor both transactions and conditions, looking for events as they occur or fail to occur.
To introduce a compliance system requires a disciplined approach and support from executives: it is after all the latter which are coming to bear personal as well as corporate liability for failure to comply with more recent legislation.
A suggested methodology is:
* Discover and record applicable legislation, industry requirements and standards.
* Determine what each of these would require in terms of compliance data to manage and audit:
- What must be monitored as part of manufacturing and business processes to ensure that operations are compliant?
- How to capture the data such that compliance can be audited.
* Evaluate how to centralise the recording of all compliance data with special consideration to:
Knowledge of all legislation, industry regulations and standards that impact an organisation is a Herculean task, but Table 1 lists some of the obvious areas in which automation systems could facilitate compliance or need to comply.
Table 1. Some areas where compliance meets automation systems
One of the conundrums of compliance management systems is that they and the compliance data stored on them must be secure:
* It must not be possible to delete or edit compliance data.
* Records should be tamper evident. Possibly encoded with checksums.
* There may be a need to encrypt data if it is economically sensitive or carries privacy obligations (eg patient records).
* Data retention (secure backup and archiving).
Any compliance management system must be auditable and that implies that at least two types of documentation are required:
* At the system level aspects like user requirements and system selection rationale, installation and testing should be documented.
* At the configuration level there should be a documented path from legislative analysis, through data selection, data collection. (Why is the system collecting the particular data and how does it prove compliance with a particular requirement?)
In terms of security, Hewlett-Packard’s paper¹ suggests that the computer systems that drive the process must meet the requirements of the National Institute of Standards and Technology (NIST) Federal Information Processing Standard FIPS 140-2 level 3 or above and also ISO 15408 rating 5 or above.
Operation: a four-step process
Once a compliance system is in place it must be operated in a disciplined manner. Hewlett-Packard, in a recent publication on compliance with the cyber security standards1, proposed a four-step process for the treatment of compliance data:
1. Check-in: Collection of compliance data.
2. Review: Review of accuracy and relevance of data by subject-matter experts.
3. Approval: Review and sign-off by responsible executive.
4. Audit: As required by internal or external resources to substantiate compliance.
Table 2. Compliance and traceability resources
Lifecycle costs and TCO
The related concepts of whole lifecycle costing (WLC) (also called life cycle costing (LCC)) and total cost of ownership (TCO) are a recurrent theme in presentations on IT and automation infrastructure investment. While the phrases trip easily off the tongues of presenters and salespeople, fully evaluating these is complex.
According to a Wikipedia entry, whole-life cost refers to the total cost of ownership over the life of an asset and is also commonly referred to as 'cradle to grave' or 'womb to tomb' costs. Typical areas of expenditure which are included in calculating the whole-life cost are:
* Financial (eg depreciation and cost of finance).
* Replacement or disposal.
From an automation systems perspective these can be categorised as costs of:
* User requirements analysis.
* Evaluation, selection and acquisition.
* Operation and maintenance.
* Disposal and replacement.
Why is WLC important?
In many cases the cost of ownership is multiples of the cost of acquisition. In a 2008 press release Gartner noted that, “For a large company, the cost of purchasing a desktop PC may be only $1200, but, kept for four years, the total cost of ownership (TCO) could be as much as $5867 per year.” Similarly, “A notebook computer may cost $1500 to buy but have a TCO of just over $9900 per year over three years.”
In both these cases the original purchase price represents about 5% of the TCO. It is likely that for automation system purchases, with lifespans of the order of 10 to 15 years, the initial capital investment would be some much smaller percentage of TCO. This means that purchasers should place far more emphasis on the ongoing costs (and economic benefits) of a system than on the cost of acquisition.
Because the costs during the operational portion of an asset’s lifecycle make up such a large proportion of the WLC, it is here that there is the greatest variability between systems’ economic performance, making it important to apply WLC principles for project cost justification and system selection.
Table 3. Whole-life cost and total cost of ownership resources
System cost drivers
When selecting systems like ERP and MES, some of the key cost drivers to consider over the life of a project are costs related to:
* Software (application licences, licence maintenance and support).
* Software infrastructure (operating system licences, database licences, training, maintenance and support on these).
* Hardware (computers, network infrastructure, firewalls, security).
* Professional services (project management, customisation, integration, data conversion, testing, validation, training, administration and user support).
* Internal costs for IT management, configuration and support.
* Change management.
In the evaluation phase of a project it is important to consider the value of integrated tools in any vendor’s offering that might reduce project acquisition costs (eg vendor A includes certain tools that would need to be purchased separately if vendor B’s proposal is accepted); that might significantly impact system maintenance costs; or that might affect productivity.
A further aspect to consider when estimating costs for this phase is the degree to which any vendor offering is aligned with accepted standards. Implementation and maintenance costs for systems closely aligned to established standards like ISA 95 should result in lower WLC.
Regulatory compliance refers to systems or departments at corporations and public agencies to ensure that personnel are aware of and take steps to comply with relevant laws and regulations. Wikipedia
Compliance data is defined as all data belonging or pertaining to enterprise or included in the law, which can be used for the purpose of implementing or validating compliance. It is the set of all data that is relevant to a governance officer or to a court of law for the purposes of validating consistency, completeness, or compliance. Wikipedia
For more information contact Andrew Ashton, Technews, +27 (0)11 886 3640, firstname.lastname@example.org, www.technews.co.za
1. Process control compliance automation and audit: the HP Trusted Compliance Solution for Energy (4AA1-2802ENA): Hewlett-Packard Development Company, Ltd., May 2007.
2. ERP Plus in Process Industries: Beyond Compliance: Aberdeen Group November 2008.