1 Scope
This document specifies the requirements related to the representation of information for technical analysis and decision support in open condition monitoring and diagnostic systems. Software design professionals need to display diagnostic or predictive data, health information, alarms and recommendations on a computer and make them available to end-users in the form of written reports. This document specifies how this information is to be displayed in a condition monitoring and diagnostic system.
2 Normative references
The contents of the following documents constitute essential provisions of this document by means of normative references in the text. Where a reference is dated, only the version corresponding to that date applies to this document; where a reference is not dated, the latest version (including all change orders) applies to this document.
3 Terminology and definitions
The terms and definitions defined in ISO 13372 apply to this document.
4 Information architecture representation requirements for open condition monitoring and diagnosis
4.1 Overview
For a given system or application, the information architecture describes all data objects and their characteristics (or attributes), data types, data relationships, referenced data and data files. In accordance with ISO 13374-2, an open condition monitoring and diagnostic information architecture specification is described in the five levels shown in Figure 1.
4.2 Basic requirements
In order to enable continuous improvement of the end-user interface including the graphical user interface, displays and reports, the OCMD information architecture should separate the representation and display functions from the information content and logic. The description of the representation interface functions is usually described using templates, but customisation is also allowed, where the templates specify the format of end-user displays and reports. The representation interface of the open condition monitoring and diagnostic information architecture shall communicate with the layer 5 data file definition and match the defined layer 4 reference database, the implementation path shall vary according to the actual application requirements.
4.3 Authentication and authorisation requirements
In computing processing, authentication is a security mechanism that allows the SoftChild system to identify the user who is using the system. The authorisation mechanism allows the system to identify the authenticated user to determine what level of access they have to protect the system resources. The Open Condition Monitoring and Diagnostic Information Architecture (OCDIA) should be user-authenticated; it is desirable to support user authorisation and to specify methods for user authentication and authorisation (if authorisation is supported).
4.4 Internationalisation and localisation requirements
In computing processing, internationalisation and localisation is a mechanism that allows software systems to be easily adapted to end-user groups in different languages, time zones, regions and with various technical requirements. Internationalisation is a requirement for designing software systems so that they can be adapted to different languages and regions without the need for engineering changes. Localisation is the process of adapting internationalised software to a specific region or language by adding region-specific plug-ins to enable text translation. The Open Condition Monitoring and Diagnostic Information Architecture should specify methods of internationalisation and localisation for end users.
4.5 User tracking requirements
The tracking of user interactions with software systems is often required to meet regulatory requirements. It is desirable that the Open Condition Monitoring and Diagnostic Information Architecture specify methods for user tracking and methods for reporting this information.
4.6 User configuration requirements
Software systems typically allow users to configure them to meet their specific needs. It is desirable that this configuration information be accessible and usable by subsequent users. The OCD information architecture should specify user configuration options.
5 Requirements for the representation of an open condition monitoring and diagnosis processing architecture
5.1 Overview
A processing architecture describes the interaction between all modules, both internal to the software system and external to the end-user or other software system. According to ISO 13374-1, the open condition monitoring and diagnostic processing architecture should be as shown in Figure 2.
This architecture is defined as the data processing function modules. When each module in the system is properly configured, the underlying data is converted into digital form in the data acquisition (DA) module and processed in a different way to convert it into executable information, resulting in the recommendation generation module (AG). During the processing from DA to AG, the data from the previous module is transferred to the later module and additional information is exchanged with external systems. Likewise, when data is converted into information, it needs to be expressed in standard technical displays and graphic representations. This document defines the technical display and information representation requirements for any open condition monitoring and diagnostic processing architecture. With this approach, data processing modules from different suppliers can be integrated into a complete functional system.
In a real-time constrained embedded environment, the system usually starts with data acquisition. The information is then processed and refined in subsequent system modules to enable it to be used for health assessment, predictive evaluation and recommendation generation. These requirements often lead to a completely different choice of technology. The representation software used to display the output of "information-oriented" modules (e.g. HA, PA and AG) is often different from that used in "data-oriented" modules (e.g. DA, DM and SD).
5.2 Technical display (TD) module requirements
The TD modules in the open condition monitoring and diagnostic processing architecture provide the required diagnostic displays and reports for the end user by analysing the monitoring data supported by the system. Each TD module should record and display its refresh method, the usual refresh rate and the time of the last update. It is also desirable for the module to include information on the rate of change, for example by plotting a trend graph to depict this.
5.3 Information representation (IP) module requirements
The IP module in an open condition monitoring and diagnostic processing architecture provides intelligent, actionable information to the end user about the current and future health of the machine and provides recommendations for subsequent operations. Both manual and automated agents can be used, but the output of each agent may differ when analysing the same inputs. To provide a clear source of information, each IP module should have a mechanism to identify the source of the intelligent agent 'analyst', the source of the condition monitoring technology used for analysis and the time of analysis. Each IP module should record and display its refresh method, the usual refresh rate and the time of the last update.
When presenting the overall health of the machine to non-specialists, the following standard terminology is appropriate for the open condition monitoring and diagnostic processing architecture:
Undetermined - condition parameters have not yet been evaluated.
Good - all monitored condition parameters are within normal limits.
Fair - some condition parameters are abnormal and require continued monitoring, but do not significantly increase the likelihood of operational incidents.
Severe but stable - some condition parameters are abnormal and an operational incident may occur, but these abnormal parameters are currently stable.
Severe - some condition parameters are abnormal and deteriorating, with an increased likelihood of an operational incident.
Critical but stable - some condition parameters are abnormal and the likelihood of an operational incident has increased significantly, but these abnormal parameters are currently stable.
Critical - some condition parameters are abnormal and continue to deteriorate, with a significant increase in the likelihood of an operational incident.
Bibliography
1 Scope
2 Normative references
3 Terminology and definitions
4 Information architecture representation requirements for open condition monitoring and diagnosis
5 Requirements for the representation of an open condition monitoring and diagnosis processing architecture
Bibliography
Standard
GB/T 25742.4-2022 Condition monitoring and diagnostics of machine systems—Data processing ,communication and presentation—Part 4：Presentation (English Version)
Standard No.
GB/T 25742.4-2022
Status
valid
Language
English
File Format
PDF
Word Count
3000 words
Price(USD)
90.0
Implemented on
2022-10-12
Delivery
via email in 1~3 business day
Detail of GB/T 25742.4-2022
Standard No.
GB/T 25742.4-2022
English Name
Condition monitoring and diagnostics of machine systems—Data processing ,communication and presentation—Part 4：Presentation
1 Scope
This document specifies the requirements related to the representation of information for technical analysis and decision support in open condition monitoring and diagnostic systems. Software design professionals need to display diagnostic or predictive data, health information, alarms and recommendations on a computer and make them available to end-users in the form of written reports. This document specifies how this information is to be displayed in a condition monitoring and diagnostic system.
2 Normative references
The contents of the following documents constitute essential provisions of this document by means of normative references in the text. Where a reference is dated, only the version corresponding to that date applies to this document; where a reference is not dated, the latest version (including all change orders) applies to this document.
3 Terminology and definitions
The terms and definitions defined in ISO 13372 apply to this document.
4 Information architecture representation requirements for open condition monitoring and diagnosis
4.1 Overview
For a given system or application, the information architecture describes all data objects and their characteristics (or attributes), data types, data relationships, referenced data and data files. In accordance with ISO 13374-2, an open condition monitoring and diagnostic information architecture specification is described in the five levels shown in Figure 1.
4.2 Basic requirements
In order to enable continuous improvement of the end-user interface including the graphical user interface, displays and reports, the OCMD information architecture should separate the representation and display functions from the information content and logic. The description of the representation interface functions is usually described using templates, but customisation is also allowed, where the templates specify the format of end-user displays and reports. The representation interface of the open condition monitoring and diagnostic information architecture shall communicate with the layer 5 data file definition and match the defined layer 4 reference database, the implementation path shall vary according to the actual application requirements.
4.3 Authentication and authorisation requirements
In computing processing, authentication is a security mechanism that allows the SoftChild system to identify the user who is using the system. The authorisation mechanism allows the system to identify the authenticated user to determine what level of access they have to protect the system resources. The Open Condition Monitoring and Diagnostic Information Architecture (OCDIA) should be user-authenticated; it is desirable to support user authorisation and to specify methods for user authentication and authorisation (if authorisation is supported).
4.4 Internationalisation and localisation requirements
In computing processing, internationalisation and localisation is a mechanism that allows software systems to be easily adapted to end-user groups in different languages, time zones, regions and with various technical requirements. Internationalisation is a requirement for designing software systems so that they can be adapted to different languages and regions without the need for engineering changes. Localisation is the process of adapting internationalised software to a specific region or language by adding region-specific plug-ins to enable text translation. The Open Condition Monitoring and Diagnostic Information Architecture should specify methods of internationalisation and localisation for end users.
4.5 User tracking requirements
The tracking of user interactions with software systems is often required to meet regulatory requirements. It is desirable that the Open Condition Monitoring and Diagnostic Information Architecture specify methods for user tracking and methods for reporting this information.
4.6 User configuration requirements
Software systems typically allow users to configure them to meet their specific needs. It is desirable that this configuration information be accessible and usable by subsequent users. The OCD information architecture should specify user configuration options.
5 Requirements for the representation of an open condition monitoring and diagnosis processing architecture
5.1 Overview
A processing architecture describes the interaction between all modules, both internal to the software system and external to the end-user or other software system. According to ISO 13374-1, the open condition monitoring and diagnostic processing architecture should be as shown in Figure 2.
This architecture is defined as the data processing function modules. When each module in the system is properly configured, the underlying data is converted into digital form in the data acquisition (DA) module and processed in a different way to convert it into executable information, resulting in the recommendation generation module (AG). During the processing from DA to AG, the data from the previous module is transferred to the later module and additional information is exchanged with external systems. Likewise, when data is converted into information, it needs to be expressed in standard technical displays and graphic representations. This document defines the technical display and information representation requirements for any open condition monitoring and diagnostic processing architecture. With this approach, data processing modules from different suppliers can be integrated into a complete functional system.
In a real-time constrained embedded environment, the system usually starts with data acquisition. The information is then processed and refined in subsequent system modules to enable it to be used for health assessment, predictive evaluation and recommendation generation. These requirements often lead to a completely different choice of technology. The representation software used to display the output of "information-oriented" modules (e.g. HA, PA and AG) is often different from that used in "data-oriented" modules (e.g. DA, DM and SD).
5.2 Technical display (TD) module requirements
The TD modules in the open condition monitoring and diagnostic processing architecture provide the required diagnostic displays and reports for the end user by analysing the monitoring data supported by the system. Each TD module should record and display its refresh method, the usual refresh rate and the time of the last update. It is also desirable for the module to include information on the rate of change, for example by plotting a trend graph to depict this.
5.3 Information representation (IP) module requirements
The IP module in an open condition monitoring and diagnostic processing architecture provides intelligent, actionable information to the end user about the current and future health of the machine and provides recommendations for subsequent operations. Both manual and automated agents can be used, but the output of each agent may differ when analysing the same inputs. To provide a clear source of information, each IP module should have a mechanism to identify the source of the intelligent agent 'analyst', the source of the condition monitoring technology used for analysis and the time of analysis. Each IP module should record and display its refresh method, the usual refresh rate and the time of the last update.
When presenting the overall health of the machine to non-specialists, the following standard terminology is appropriate for the open condition monitoring and diagnostic processing architecture:
Undetermined - condition parameters have not yet been evaluated.
Good - all monitored condition parameters are within normal limits.
Fair - some condition parameters are abnormal and require continued monitoring, but do not significantly increase the likelihood of operational incidents.
Severe but stable - some condition parameters are abnormal and an operational incident may occur, but these abnormal parameters are currently stable.
Severe - some condition parameters are abnormal and deteriorating, with an increased likelihood of an operational incident.
Critical but stable - some condition parameters are abnormal and the likelihood of an operational incident has increased significantly, but these abnormal parameters are currently stable.
Critical - some condition parameters are abnormal and continue to deteriorate, with a significant increase in the likelihood of an operational incident.
Bibliography
Contents of GB/T 25742.4-2022
1 Scope
2 Normative references
3 Terminology and definitions
4 Information architecture representation requirements for open condition monitoring and diagnosis
5 Requirements for the representation of an open condition monitoring and diagnosis processing architecture
Bibliography
