======================= Requirements for Models ======================= .. toctree:: :maxdepth: 2 General Requirements ==================== Independence from Applications ------------------------------ Different models for different applications would result in unmanageable complexity. Thus, models should be adequate for several applications, including at least :ref:`data transfer `, :ref:`data linking `, and :ref:`data consolidation `. Independence from Implementations --------------------------------- Models should be independent from file formats, APIs, protocols, etc., to make them as independent as possible from future technical developments and from the technologies preferred in certain domains. Instead, models should be described in an implementation-independent standard and provide simple and systematic mappings to the required implementations. Usage of Established Standard as Semantic Foundation ---------------------------------------------------- When possible, established domain standards should be used as the semantic foundation of the information model. This way, the integration of existing information is simplified. Further, acceptance of the information model in the respective domain can be improved. Incremental Usefulness ---------------------- Our approach for data integration targets at large-scale applications, comprising the integration of different life cycle phases with inconsistent data in several tools, formats, etc. Thus, a short-term realization of the entire approach is not feasible. Hence, even partial implementations should provide benefits for the user in order to motivate the incremental realization of a comprehensive implementation. Extendability ------------- Due to future technical developments (e.g., new types of apparatuses) or business requirements (e.g., integration with the information systems of equipment providers), the required expressiveness for information models is likely to increase in the future. Thus, it should be possible to extend the information models in a way that does not affect existing information. Support for Distributed Models ------------------------------ Models must provide a reliable approach for references to external entities in order to allow the integration of data residing in different systems at different stakeholders. For example, it should be possible to link specific information about an asset (located in the IT system of an O/O) with general information about the equipment types (located in the IT system of a manufacturer). Open World Paradigm ------------------- The absence of information must not imply that a certain statement does not hold. Example: An instance model does not state that a certain pump in a plant is a realization of a certain pumping function in a related block flow diagram. However, this statement may still hold. Usability --------- It must be possible to encapsulate the anticipated internal complexity of the model. The model should provide different layers for different user groups (e.g., simple models for domain experts vs. more formal models for IT experts). Security and User's Rights -------------------------- While security is mainly an issue of a system implementing the models, there are some aspects that are related to models. There should be a way to structure information such that certain rights (e.g, to read/change/add/exchange information) can be assigned to certain users/user groups. For example, in a relational database system, user rights can be managed for each individual table. However, in a graph model such as RDF, there is no such structure; an RDF graph is essentially a set of triples. One option could be to use partial graphs. Content ======= Models must cover the four life cycle phases of chemical plants as identified by the ENPRO-DI group: - functional requirements, - functional design, - asset specification, - asset in operation. Models must be able to represent the relevant information in a way that does not depend on the documents in which (part of) the information is stored. For example, information about a chemical process should be represented independently from its representation in, for instance, a simulation model or a block diagram. The relations between the information items in the life cycle must be covered. In particular, this concerns relations across the boundaries of the life cycle phases. Models should also cover additional aspects related to the main scope, including - work process information, - versions and changes of information, - design rationale and other decisions. .. later? physical objects aaainformation about actual objects aaaspecifications aaaother information, e.g., simulation, measured data aaaroles: required, replacement, ... activities aaaplant operation aaaprocess design and development, engineering aaapersons aaaesign rationale and other decisions aaaxternal information storage (e.g., documents, databases): location, format, content aaaersions/changes aaarelations between these information items later aaamodules Scalability