127 lines
5.1 KiB
ReStructuredText
127 lines
5.1 KiB
ReStructuredText
|
|
Information Management Plan
|
|
===========================
|
|
|
|
Purpose
|
|
-------
|
|
This plan is the highest-level description of how information is
|
|
managed at |inst|. It defines the information management requirements
|
|
and explains the chosen processes and tools that meet the requirements.
|
|
|
|
Scope
|
|
-----
|
|
This plan applies to creation, storage, exchange, and retirement of project
|
|
information related to |project|. This includes plant configuration management
|
|
data as defined in :cite:p:`barrieroInformationManagementProcess2010`. The plan
|
|
is not limited to information affecting quality, it also includes business
|
|
information.
|
|
|
|
|
|
Background
|
|
----------
|
|
The potential benefits of the digital transformation are well known across all
|
|
business sectors. Numerous commercial nuclear information management studies
|
|
have further suggested that properly implemented information management can improve
|
|
efficiency and quality while reducing costs
|
|
:cite:p:`halpinInformationManagementNuclear1978d,agencyInformationTechnologyNuclear2010,barrieroInformationManagementProcess2010,renuartAdvancedNuclearTechnology2014`
|
|
In addition, management of information related to product quality is subject
|
|
to nuclear quality regulations in all jurisdictions.
|
|
|
|
Requirements
|
|
------------
|
|
|
|
.. req:: Quality-related information shall be managed in accordance with 10 CFR 50 Appendix B
|
|
:id: R_INFO_APPB
|
|
:links: R_10CFR50_APPB
|
|
:tags: quality
|
|
:basis: Compliance with Appendix B is necessary for licensing
|
|
|
|
Note that non-quality related information is not necessarily subject
|
|
to this requirement.
|
|
|
|
.. req:: A data dictionary shall be maintained defining controlled data
|
|
:id: R_DATA_DICT
|
|
:basis: It will provide a central reference for all project members to
|
|
find specific, precise, and up-to-date data definitions to enable
|
|
unambiguous communications and collaboration.
|
|
|
|
The dictionary shall define data types, data fields, constraints on the
|
|
fields, relationships between the data, source, sensitivity, usage,
|
|
owner/steward, sample values, and transformation logic, as applicable. It
|
|
shall be revision controlled such that changes can be clearly seen and
|
|
remembered.
|
|
|
|
.. req:: Data shall be managed such that data exchanges and transformations between
|
|
parties and systems can be readily automated
|
|
:id: R_DATA_EXCHANGE
|
|
:basis: Over the project life, numerous parties and systems will ramp up
|
|
and down due to changing relationships and technologies. Automated data
|
|
exchanges are expected to improve the ease, cost, speed, and quality of
|
|
the inevitable exchanges and transformations.
|
|
|
|
This effectively requires rich data import and export capabilities
|
|
in each tool used to manage data.
|
|
|
|
.. req:: Data shall be subject to role-based access controls (RBAC) or stronger
|
|
:id: R_DATA_ACCESS
|
|
:basis: Role-based access control (RBAC) is a strong standard
|
|
covering the needs of commercial nuclear information
|
|
from export control and business sensitivity perspectives.
|
|
|
|
More sensitive data, such as Security Related Information,
|
|
may use stronger access controls such as ABAC or MAC.
|
|
|
|
Implementation
|
|
--------------
|
|
This section defines the specific implementation of the requirements.
|
|
|
|
General principles
|
|
^^^^^^^^^^^^^^^^^^
|
|
A hub data architecture has been chosen for this project, based on
|
|
arguments and experiences in :cite:p:`agencyInformationTechnologyNuclear2010`.
|
|
|
|
.. figure:: /_static/data-hub.png
|
|
|
|
Hub architecture, from :cite:p:`agencyInformationTechnologyNuclear2010`
|
|
|
|
This is designed to enable rapid integration of a wide variety of partner
|
|
organizations, specialized information management tools, and engineering/design
|
|
tools while striving to future-proof the multi-decade project.
|
|
|
|
The underlying data layer consists of:
|
|
|
|
* Structured text (e.g. YAML, XML, JSON) controlled in version-controlled repositories
|
|
* Databases (e.g. Postgres)
|
|
* Documents/drawings (PDFs, native files, HTML) stored on corporate drives and managed
|
|
by the Records Management/Document Control system
|
|
* Technical data (3D models, simulation input/output, laser scans, schedule dumps) stored
|
|
on corporate drives, managed by the Technical Data Management system
|
|
|
|
Above the data layer sits the data authoring and manipulation layer, which includes:
|
|
|
|
* Office tools: word processors, spreadsheets, text editors, IDEs, etc., including
|
|
online collaboration tools
|
|
* PM tools: Primavera P6, HR tools
|
|
* Engineering tools: SolidWorks, ANSYS, CASMO, MCNP, Intergraph, Revit
|
|
* Construction tools
|
|
* Maintenance tools
|
|
|
|
One-way or bidirectional data exchanges between tools and institutions occur
|
|
through the API, which reads the data layer and presents data representations to
|
|
authorized users or services in clearly-defined formats over the network.
|
|
|
|
.. _info-mgmt-data-dict:
|
|
|
|
Data Dictionary
|
|
^^^^^^^^^^^^^^^
|
|
The data dictionary is defined and maintained as described in
|
|
:need:`I_DATA_DICT`.
|
|
|
|
The data dictionary itself is located at :ref:`data-dict`.
|
|
|
|
|
|
.. insert render of the data dictionary table here.
|
|
|
|
Technology stack
|
|
^^^^^^^^^^^^^^^^
|
|
.. insert render of the IT systems table here.
|