Loading...
Overview of advantages

The ISA-18 standard is developed with the objective to reduce the cost, risk and errors associated with implementing interfaces between enterprise and production control systems.

  • Reduce cost


    ISA-18 can be used as a method to define the interface between enterprise and production control systems.
    By applying ISA-18, costs can be reduced. You will know where to begin and how to continue.
    Don’t try to re-invent the wheel.
    The integration of solutions from different suppliers will get less complex when you all use this standard method.



  • Reduce risk and avoid errors


    ISA-18 was developed by a group of companies like Honeywell, Sequencia, Foxboro, Yokogawa, Fisher Rosemount, Chevron, Dow Chemical, SAP, and a lot more.
    These big international companies have years of experience with integration projects.
    They have combined their best practices into a consistent set of models and terminology: the ISA-18 standard.
    They know how to make integration a success and, more important, how to avoid failures!
    You can use these best practices by applying the standard.



  • Improve Communication


    Every manufacturing company uses its own terminology for describing functions, activities and departments within the enterprise.
    When you have to work with external consultants, like suppliers of process control software, or system integrators, communication will be difficult.
    There is a big chance that you will refer to different things when using the same terms, or the other way around.
    The external specialist will have to deal with this problem every time they start a new project, or every time they are talking with different clients.
    So when you discuss interfaces, it’s a good idea to base this discussion on standard terminology.
    Note: It won’t be necessary to adapt the existing names of the information in systems or departments.



Where can ISA-18 be used for?

  • Use the hierarchical models to define how your company is structured, when discussing departments and automation systems;
  • Use the functional model to determine which departments and systems are responsible for the functions of interest;
  • Use the functional model to determine which information flows from one department to another department, and which information flows from one automation system to another automation system;
  • Use the definition of functions and information flows as a checklist, making sure that you’re not forgetting anything;
  • Use the definition of functions and information flows as a dictionary, making sure that everybody is talking about the same thing;
  • Use the object models to understand the relationship between different sorts of information;
  • Use the object models and the attributes to exchange information;
  • Use the object models and attributes as a basis for a database;
  • Use the activity models from part 3 for the specification of User Requirements;
  • Use the activity models from part 3 for vendor / solution selections; and so on.