This part of IEC 62769 specifies an FDI profile for IEC 62734 (ISA100 WIRELESS) 1.

  • Standard
    33 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 describes the concepts and overview of the Field Device Integration
(FDI) specifications. The detailed motivation for the creation of this technology is also described
(see 4.1). Reading this document is helpful to understand the other parts of this multi-part
standard.

  • Standard
    32 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 defines the FDI Information Model. One of the main tasks of the
Information Model is to reflect the topology of the automation system. Therefore, it represents
the devices of the automation system as well as the connecting communication networks
including their properties, relationships, and the operations that can be performed on them.
The types in the AddressSpace of the FDI Server constitute a catalogue, which is built from
FDI Packages.
The fundamental types for the FDI Information Model are well defined in OPC UA for Devices
(IEC 62541-100). The FDI Information Model specifies extensions for a few special cases and
otherwise explains how these types are used and how the contents are built from elements of
DevicePackages.
The overall FDI architecture is illustrated in Figure 1. The architectural components that are
within the scope of this document have been highlighted in this illustration.

  • Standard
    68 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies the FDI Client. The overall FDI architecture is illustrated in
Figure 1. The architectural components that are within the scope of this document have been
highlighted in this figure.

  • Standard
    156 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies the technology mapping for the concepts described in the
Field Device Integration (FDI) standard. The technology mapping focuses on implementation
regarding the components FDI Client and User Interface Plug-in (UIP) that are specific only to
the WORKSTATION platform/.NET as defined in IEC 62769-4.

  • Standard
    30 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Draft
    25 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies the FDI Server. The overall FDI architecture is illustrated in
Figure 1. The architectural components that are within the scope of this document have been
highlighted in this figure.

  • Standard
    65 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies the FDI Packages. The overall FDI architecture is illustrated
in Figure 1. The architectural components that are within the scope of this document have
been highlighted in Figure 1.

  • Standard
    85 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies the elements implementing communication capabilities called
Communication Devices (IEC 62769-5).
The overall FDI architecture is illustrated in Figure 1. The architectural components that are
within the scope of this document have been highlighted in this illustration. The document
scope with respect to FDI Packages is limited to Communication Devices. The Communication
Server shown in Figure 1 is an example of a specific Communication Device.

  • Standard
    67 pages
    English language
    sale 10% off
    e-Library read for
    1 day

IEC 62769-101-2:2020 is available as IEC 62769-101-2:2020 RLV which contains the International Standard and its Redline version, showing all changes of the technical content compared to the previous edition.

IEC 62769-101-2:2020 specifies the IEC 62769 profile for IEC 61784 1, CP 1/2 (FOUNDATION™ Fieldbus HSE).

  • Standard
    31 pages
    English language
    sale 10% off
    e-Library read for
    1 day

IEC 62769-101-1:2020 is available as IEC 62769-101-1:2020 RLV which contains the International Standard and its Redline version, showing all changes of the technical content compared to the previous edition.

IEC 62769-101-1:2020 specifies the IEC 62769 profile for IEC 61784 1_CP 1/1 (FOUNDATION™ Fieldbus H1) .

  • Standard
    34 pages
    English language
    sale 10% off
    e-Library read for
    1 day

IEC 62769-150-1:2021 specifies an FDI profile for IEC 62734 (ISA100 WIRELESS)

  • Standard
    57 pages
    English and French language
    sale 15% off

This part of IEC 62351 specifies messages, procedures, and algorithms for securing the
operation of all protocols based on or derived from the IEC 61850 series.The initial audience for this document is intended to be the members of the working groups
developing or making use of the protocols listed in Table 1. For the measures described in this
specification to take effect, they must be accepted and referenced by the specifications for the
protocols themselves. This document is written to enable that process.
The subsequent audience for this document is intended to be the developers of products that
implement these protocols.
Portions of this document may also be of use to managers and executives in order to understand
the purpose and requirements of the work.

  • Standard
    37 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 defines the protocol-specific definitions (PSDs) as defined in
IEC 62769-7 on generic protocol extensions for the Modbus®1-RTU protocol in accordance
with CPF 15 in IEC 61784-2.

  • Standard
    15 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    15 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies an FDI profile of IEC 62769 for generic protocols. That
means that all interfaces are defined, and a host can add support for more protocols without
changing its implementation. Nevertheless, there are some protocol-specific definitions (PSD)
that need to be specified per protocol using this profile. Annex C specifies what PSDs need to
be defined per protocol so that FDI Device Packages, FDI Communication Packages for
Gateways and FDI Communication Servers, FDI Communication Servers, Gateways and
Devices supporting such a protocol can work together in a host not aware about this specific
protocol.
NOTE A host not using an FDI Communication Server but a proprietary mechanism for communication defines its
own means to deal with this profile to support several protocols without changing its implementation. This is
specific to the proprietary way how the communication driver is bound to the host.

  • Standard
    40 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 defines the OPC Unified Architecture (OPC UA) PubSub
communication model. It defines an OPC UA publish subscribe pattern which complements
the client server pattern defined by the Services in IEC 62541-4. IEC TR 62541-1 gives an
overview of the two models and their distinct uses.
PubSub allows the distribution of data and events from an OPC UA information source to
interested observers inside a device network as well as in IT and analytics cloud systems.
This document consists of
• a general introduction of the PubSub concepts,
• a definition of the PubSub configuration parameters,
• mapping of PubSub concepts and configuration parameters to messages and transport
protocols, and
• a PubSub configuration model.
Not all OPC UA Applications will need to implement all defined message and transport
protocol mappings. IEC 62541-7 defines the Profile that dictates which mappings need to be
implemented in order to be compliant with a particular Profile.

  • Standard
    192 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 defines the Information Model of the OPC Unified Architecture. The
Information Model describes standardized Nodes of a Server’s AddressSpace. These Nodes
are standardized types as well as standardized instances used for diagnostics or as entry
points to server-specific Nodes. Thus, the Information Model defines the AddressSpace of an
empty OPC UA Server. However, it is not expected that all Servers will provide all of these
Nodes.

  • Standard
    187 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 defines the OPC Unified Architecture (OPC UA) Services. The
Services defined are the collection of abstract Remote Procedure Calls (RPC) that are
implemented by OPC UA Servers and called by OPC UA Clients. All interactions between
OPC UA Clients and Servers occur via these Services. The defined Services are considered
abstract because no particular RPC mechanism for implementation is defined in this
document. IEC 62541‑6 specifies one or more concrete mappings supported for
implementation. For example, one mapping in IEC 62541‑6 is to XML Web Services. In that
case the Services described in this document appear as the Web service methods in the
WSDL contract.
Not all OPC UA Servers will need to implement all of the defined Services. IEC 62541‑7
defines the Profiles that dictate which Services need to be implemented in order to be
compliant with a particular Profile.

  • Standard
    232 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62451 defines the information model associated with Programs in the OPC
Unified Architecture. This includes the description of the NodeClasses, standard Properties,
Methods and Events and associated behaviour and information for Programs.
The complete Address Space model including all NodeClasses and Attributes is specified in
IEC 62541‑3. The Services such as those used to invoke the Methods used to manage
Programs are specified in IEC 62541‑4.

  • Standard
    48 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document analyses visualization elements that are key components of the interface between the physical asset and the avatar (digital replica of the physical asset).

  • Technical report
    19 pages
    English language
    sale 15% off
  • Draft
    19 pages
    English language
    sale 15% off

This part of IEC 62714 specifies the integration of logic information as part of an AML model
for the data exchange in a heterogenous engineering tool landscape of production systems.
This document specifies three types of logic information: sequencing, behaviour, and
interlocking information.
This document deals with the six following sequencing and behaviour logic models (covering
the different phases of the engineering process of production systems) and how they are
integrated in AML: Gantt chart, activity-on-node network, timing diagram, Sequential Function
Chart (SFC), Function Block Diagram (FBD), and mathematical expression.
This document specifies how to model Gantt chart, activity-on-node network, and timing
diagram and how they are stored in Intermediate Modelling Layer (IML).
NOTE 1 With this, it is possible to transform one logic model into another one. A forward transformation supports
the information enrichment process and reduces or avoids a re-entry of information between the exchanging
engineering tools.
NOTE 2 Mapping of other logic models, e.g. event-driven logic models like state charts, onto IML is possible.
This document specifies how interlocking information is modelled (as interlocking source and
target groups) in AML. The interlocking logic model is stored in Function Block Diagram (FBD).
This document specifies the AML logic XML schema that stores the logic models by using
IEC 61131-10.
This document specifies how to reference PLC programs stored in PLCopen XML documents.
This document does not define details of the data exchange procedure or implementation
requirements for the import/export tools.

  • Standard
    113 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 specifies how OPC Unified Architecture (OPC UA) Clients and Servers
interact with DiscoveryServers when used in different scenarios. It specifies the requirements
for the LocalDiscoveryServer, LocalDiscoveryServer-ME and GlobalDiscoveryServer. It also
defines information models for Certificate management, KeyCredential management and
Authorization Services.

  • Standard
    107 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 defines the OPC Unified Architecture (OPC UA) Profiles. The Profiles
in this document are used to segregate features with regard to testing of OPC UA products
and the nature of the testing (tool based or lab based). This includes the testing performed by
the OPC Foundation provided OPC UA CTT (a self-test tool) and by the OPC Foundation
provided Independent certification test labs. This could equally as well refer to test tools
provided by another organization or a test lab provided by another organization. What is
important is the concept of automated tool-based testing versus lab-based testing. The scope
of this standard includes defining functionality that can only be tested in a lab and defining the
grouping of functionality that is to be used when testing OPC UA products either in a lab or
using automated tools. The definition of actual TestCases is not within the scope of this
document, but the general categories of TestCases are within the scope of this document.
Most OPC UA applications will conform to several, but not all, of the Profiles.

  • Standard
    128 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 is part of the OPC Unified Architecture standard series and defines the
information model associated with Historical Access (HA). It particularly includes additional
and complementary descriptions of the NodeClasses and Attributes needed for Historical
Access, additional standard Properties, and other information and behaviour.
The complete AddressSpace Model including all NodeClasses and Attributes is specified in
IEC 62541-3. The predefined Information Model is defined in IEC 62541-5. The Services to
detect and access historical data and events, and description of the ExtensibleParameter
types are specified in IEC 62541-4.
This document includes functionality to compute and return Aggregates like minimum,
maximum, average etc. The Information Model and the concrete working of Aggregates are
defined in IEC 62541-13.

  • Standard
    55 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 specifies the representation of Alarms and Conditions in the OPC
Unified Architecture. Included is the Information Model representation of Alarms and
Conditions in the OPC UA address space. Other aspects of alarm systems such as alarm
philosophy, life cycle, alarm response times, alarm types and many other details are captured
in documents such as IEC 62682 and ISA 18.2. The Alarms and Conditions Information Model
in this specification is designed in accordance with IEC 62682 and ISA 18.2.

  • Standard
    134 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 defines the OPC Unified Architecture (OPC UA) AddressSpace and its
Objects. This document is the OPC UA meta model on which OPC UA information models are
based.

  • Standard
    125 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 61804 specifies EDD interpretation for EDD applications and EDDs to support
EDD interoperability. This document is intended to ensure that field device developers use the
EDDL constructs consistently and that the EDD applications have the same interpretations of
the EDD. It supplements the EDDL specification to promote EDDL application interoperability
and improve EDD portability between EDDL applications.

  • Standard
    142 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 61804 specifies the EDDL builtin library and provides the profiles of the various
fieldbuses.

  • Standard
    282 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 specifies the OPC Unified Architecture (OPC UA) mapping between
the security model described in IEC TR 62541‑2, the abstract service definitions specified in
IEC 62541‑4, the data structures defined in IEC 62541‑5 and the physical network protocols
that can be used to implement the OPC UA specification.

  • Standard
    122 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 is part of the overall OPC Unified Architecture specification series and
defines the information model associated with Aggregates.

  • Standard
    113 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62541 is part of the overall OPC Unified Architecture (OPC UA) standard series
and defines the information model associated with Data Access (DA). It particularly includes
additional VariableTypes and complementary descriptions of the NodeClasses and Attributes
needed for Data Access, additional Properties, and other information and behaviour.
The complete address space model, including all NodeClasses and Attributes is specified in
IEC 62541-3. The services to detect and access data are specified in IEC 62541-4.

  • Standard
    53 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 61804 specifies the electronic device description language (EDDL)
technology, which enables the integration of real product details using the tools of the
engineering life cycle.
This document specifies EDDL as a generic language for describing the properties of
automation system components. EDDL is capable of describing
• device parameters and their dependencies;
• device functions, for example, simulation mode, calibration;
• graphical representations, for example, menus;
• interactions with control devices;
• graphical representations:
– enhanced user interface,
– graphing system;
• persistent data store.
EDDL is used to create electronic device description (EDD) for e.g. concrete devices,
common usable profiles or libraries. This EDD is used with appropriate tools to generate an
interpretative code to support parameter handling, operation, and monitoring of automation
system components such as remote I/Os, controllers, sensors, and programmable controllers.
Tool implementation is outside the scope of this document.
This document specifies the semantic and lexical structure in a syntax-independent manner. A
specific syntax is defined in Annex A, but it is possible to use the semantic model also with
different syntaxes.
IEC 61804-4 specifies EDD interpretation for EDD applications and EDDs to support EDD
interoperability.
IEC 61804-5 specifies the EDDL builtin library and provides the profiles of the various
fieldbuses.

  • Standard
    396 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies an FDI profile of IEC 62769 for IEC 61784-2_CP 3/4,
IEC 61784-2_CP3/5 and IEC 61784-2_CP3/6 (PROFINET1).

  • Standard
    36 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies an FDI profile of IEC 62769 for IEC 61784-1_CP 9/1
(HART®)1 and IEC 61784-1_CP 9/2 (WirelessHART®)1.

  • Standard
    42 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62769 specifies an FDI profile of IEC 62769 for IEC 61784-1_CP 3/1
(PROFIBUS DP)1 and IEC 61784-1_CP3/2 (PROFIBUS PA)1.

  • Standard
    34 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This part of IEC 62056 describes how the DLMS/COSEM Application layer and the COSEM
object model as specified in IEC 62056‑5‑3:2017, IEC 62056‑6‑1:2017 and IEC 62056‑6‑2:2017
can be used over the lower layers specified in the IEC 14908 series, forming a DLMS/COSEM
ISO/IEC 14908 communication profile.
This document is part of the IEC 62056 series. Its structure follows IEC 62056-1-0 and
IEC TS 62056-1-1.
Annex A (informative) provides examples of representative instances of data exchange.
NOTE This Annex A is included and referenced for consistency with other parts of the IEC 62056 suite, but it is
empty.
Annex B (normative) defines COSEM interface classes and related OBIS codes for setting up
and managing the DLMS/COSEM communication profile for IEC 14908 networks. These
interface classes and OBIS codes will be moved later to IEC 62056-6-2 and IEC 62056-6-1.
Annex C (informative) provides an implementation guide and specifies a migration path from
Utility Tables based applications to DLMS/COSEM based applications.
Annex D (informative) specifies the OSGP-AES-128-PSK security suite for optional use on the
adaptation layer level.
Annex E (normative) specifies the repeating mechanism over the ISO 14908-3 Power Line
Channel network.
Annex F (informative) specifies ISO/IEC 14908-3 Registration and monitoring of LNAPs.

  • Standard
    104 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The scope of this part of IEC 62351 is to facilitate role-based access control (RBAC) for power
system management. RBAC assigns human users, automated systems, and software
applications (collectively called "subjects" in this document) to specified "roles", and restricts
their access to only those resources, which the security policies identify as necessary for their
roles.
As electric power systems become more automated and cyber security concerns become more
prominent, it is becoming increasingly critical to ensure that access to data (read, write, control,
etc.) is restricted. As in many aspects of security, RBAC is not just a technology; it is a way of
running a business. RBAC is not a new concept; in fact, it is used by many operating systems
to control access to system resources. Specifically, RBAC provides an alternative to the all-ornothing
super-user model in which all subjects have access to all data, including control
commands.
RBAC is a primary method to meet the security principle of least privilege, which states that no
subject should be authorized more permissions than necessary for performing that subject’s
task. With RBAC, authorization is separated from authentication. RBAC enables an organization
to subdivide super-user capabilities and package them into special user accounts termed roles
for assignment to specific individuals according to their associated duties. This subdivision
enables security policies to determine who or what systems are permitted access to which data
in other systems. RBAC provides thus a means of reallocating system controls as defined by
the organization policy. In particular, RBAC can protect sensitive system operations from
inadvertent (or deliberate) actions by unauthorized users. Clearly RBAC is not confined to
human users though; it applies equally well to automated systems and software applications,
i.e., software parts operating independent of user interactions.
The following interactions are in scope:
– local (direct wired) access to the object by a human user, a local and automated computer
agent, or a built-in HMI or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated computer
agent, e.g. another object at another substation, a distributed energy resource at an enduser’s
facility, or a control centre application.
While this document defines a set of mandatory roles to be supported, the exchange format for
defined specific or custom roles is also in scope of this document.
Out of scope for this document are all topics which are not directly related to the definition of
roles and access tokens for local and remote access, especially administrative or organizational
tasks, such as:
– user names and password definitions/policies;
– management of keys and/or key exchange;
– engineering process of roles;
– assignment of roles;
– selection of trusted certificate authorities issuing credentials (access tokens);
– defining the tasks of a security officer;
– integrating local policies in RBAC;
NOTE Specifically, the management of certificates is addressed in IEC 62351-9.
Existing standards (see ANSI INCITS 359-2004, IEC 62443 (all parts), and IEEE 802.1X-2004)
in process control industry and access control (RFC 2904 and RFC 2905) are not sufficient as
none of them specify neither the exact role name and associated permissions nor the format of
the access tokens nor the detailed mechanism by which access tokens are transferred to and
authenticated by the target system – all this information is needed though for interoperability.
On the other hand, IEEE 1686 already defines a minimum number of roles to be supported as
well as permissions, which are to be addressed by the roles. Note that IEEE 1686 is currently
being revised.

  • Standard
    77 pages
    English language
    sale 10% off
    e-Library read for
    1 day

IEC 61804-3:2020 specifies the electronic device description language (EDDL) technology, which enables the integration of real product details using the tools of the engineering life cycle.
This document specifies EDDL as a generic language for describing the properties of automation system components. EDDL is capable of describing
• device parameters and their dependencies;
• device functions, for example, simulation mode, calibration;
• graphical representations, for example, menus;
• interactions with control devices;
• graphical representations:
– enhanced user interface,
– graphing system;
• persistent data store.
EDDL is used to create electronic device description (EDD) for e.g. concrete devices, common usable profiles or libraries. This EDD is used with appropriate tools to generate an interpretative code to support parameter handling, operation, and monitoring of automation system components such as remote I/Os, controllers, sensors, and programmable controllers. Tool implementation is outside the scope of this document.
This document specifies the semantic and lexical structure in a syntax-independent manner. A specific syntax is defined in Annex A, but it is possible to use the semantic model also with different syntaxes.
IEC 61804-4 specifies EDD interpretation for EDD applications and EDDs to support EDD interoperability.
IEC 61804-5 specifies the EDDL builtin library and provides the profiles of the various fieldbuses. This fourth edition cancels and replaces the third edition published in 2015. This edition constitutes a technical revision.
This edition was developed by merging material from multiple variants of existing EDDL specifications including those from FieldComm Group (FOUNDATION™ Fieldbus , HART® ), PROFIBUS™ Nutzerorganisation e.V. (PNO), and ISA100_Wireless™ Compliance Institute (ISA100 WCI). Any places where there may be a profile deviation are now indicated in the context where the related deviation is found. As a result, the formatting and numbering of this edition may be different from any of the individual specifications from which this edition was derived.
This edition includes the following significant technical changes with respect to the previous edition:
• Communication profiles ISA100 and GPE were added.
• EDD Identification Information has a new LAYOUT_TYPE attribute.
• New construct SEMANTIC_MAP was added.
• CLASS attribute values LOCAL_A and LOCAL_B were added.
• Extended LIST functionality to support device managed lists.

  • Standard
    795 pages
    English and French language
    sale 15% off

IEC 61804-4:2020 specifies EDD interpretation for EDD applications and EDDs to support EDD interoperability. This document is intended to ensure that field device developers use the EDDL constructs consistently and that the EDD applications have the same interpretations of the EDD. It supplements the EDDL specification to promote EDDL application interoperability and improve EDD portability between EDDL applications. This second edition cancels and replaces the first edition published in 2015. This edition constitutes a technical revision.
This edition was developed by merging material from multiple variants of existing EDDL specifications including those from FieldComm Group (Foundation™ Fieldbus , HART® ), PROFIBUS™ Nutzerorganisation e.V. (PNO), and ISA100_Wireless™ Compliance Institute (ISA100 WCI). When a profile deviation exists, it is now indicated in the context where the related deviation is found. As a result, the formatting and numbering of this edition may be different from any of the individual specifications from which this edition was derived.
This edition includes the following significant technical changes with respect to the previous edition:
• communication profiles ISA100 and GPE were added;
• description of rules for optimized-column-width layout have been added;
• description of the concatenation of labels and help was added;
• color banding for meter type charts was added.

  • Standard
    291 pages
    English and French language
    sale 15% off

IEC 61804-5:2020 specifies the EDDL builtin library and provides the profiles of the various fieldbuses. This second edition cancels and replaces the first edition published in 2015. This edition constitutes a technical revision.
This edition was developed by merging material from multiple variants of existing EDDL specifications including those from FieldComm Group (Foundation™ Fieldbus , HART® ), PROFIBUS™ Nutzerorganisation e.V. (PNO), and ISA100_Wireless™ Compliance Institute (ISA100 WCI). As a result, the formatting and numbering of this edition may be different from any of the individual specifications from which this edition was derived.
This edition includes the following significant technical changes with respect to the previous edition:
• Communication profiles ISA100 and GPE were added.
• The following builtins have been deprecated:
– ABORT_ON_NO_DEVICE
– IGNORE_NO_DEVICE
– RETRY_ON_NO_DEVICE
– XMTR_ABORT_ON_NO_DEVICE
– XMTR_IGNORE_NO_DEVICE
– XMTR_RETRY_ON_NO_DEVICE
– get_status_code_string

  • Standard
    569 pages
    English and French language
    sale 15% off

This document provides the specification for the Additive Manufacturing File Format (AMF), an
interchange format to address the current and future needs of additive manufacturing technology.
This document specifies the requirements for the preparation, display and transmission for the AMF.
When prepared in a structured electronic format, strict adherence to an extensible markup language
(XML)[1] schema supports standards-compliant interoperability.
NOTE A W3C XML schema definition (XSD) for the AMF is available from ISO from http:// standards .iso .org/
iso/ 52915 and from ASTM from www .astm .org/ MEETINGS/ images/ amf .xsd. An implementation guide for such
an XML schema is provided in Annex A.
It is recognized that there is additional information relevant to the final part that is not covered by the
current version of this document. Suggested future features are listed in Annex B.
This document does not specify any explicit mechanisms for ensuring data integrity, electronic
signatures and encryptions.

  • Standard
    35 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    35 pages
    English language
    sale 10% off
    e-Library read for
    1 day

ISO/IEC TR 30166:2020 (E) describes the following:
• general Industrial IoT (IIoT) systems and landscapes which outline characteristics, technical aspects and functional as well as non-functional elements of the IIoT structure and a listing of standardizing organisations, consortia and open-source communities with work on all aspects on IIoT;
• considerations for the future standardization perspective of IIoT including risk analysis, new technologies and identified collaboration

  • Technical report
    88 pages
    English language
    sale 15% off

This document provides the specification for the Additive Manufacturing File Format (AMF), an interchange format to address the current and future needs of additive manufacturing technology.
This document specifies the requirements for the preparation, display and transmission for the AMF. When prepared in a structured electronic format, strict adherence to an extensible markup language (XML)[1] schema supports standards-compliant interoperability.
NOTE A W3C XML schema definition (XSD) for the AMF is available from ISO from http://standards.iso.org/iso/52915 and from ASTM from www.astm.org/MEETINGS/images/amf.xsd. An implementation guide for such an XML schema is provided in Annex A.
It is recognized that there is additional information relevant to the final part that is not covered by the current version of this document. Suggested future features are listed in Annex B.
This document does not specify any explicit mechanisms for ensuring data integrity, electronic signatures and encryptions.

  • Standard
    35 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    35 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document provides the specification for the Additive Manufacturing File Format (AMF), an interchange format to address the current and future needs of additive manufacturing technology. This document specifies the requirements for the preparation, display and transmission for the AMF. When prepared in a structured electronic format, strict adherence to an extensible markup language (XML)[1] schema supports standards-compliant interoperability. NOTE A W3C XML schema definition (XSD) for the AMF is available from ISO from http://standards.iso.org/iso/52915 and from ASTM from www.astm.org/MEETINGS/images/amf.xsd. An implementation guide for such an XML schema is provided in Annex A. It is recognized that there is additional information relevant to the final part that is not covered by the current version of this document. Suggested future features are listed in Annex B. This document does not specify any explicit mechanisms for ensuring data integrity, electronic signatures and encryptions.

  • Standard
    27 pages
    English language
    sale 15% off
  • Standard
    27 pages
    French language
    sale 15% off

This European Standard applies to controller device interfaces that provide defined interfaces between low voltage switchgear, controlgear, control circuit devices, switching elements and controlling devices (e.g. programmable controllers, personal computers, etc.). It may also be applied for the interfacing of other devices and elements to a controller device interface.
This standard specifies requirements for controllers and devices utilising these interfaces, including not only the communication protocol specification, but also associated relevant electrical and mechanical characteristics.  It also specifies the electrical and EMC tests required to verify the performance of each controller device interface when connected to the appropriate controllers and devices.
This part 1 establishes a consistent terminology and format for the subsequent interfaces.  It also harmonises requirements of a general nature in order to reduce the need for testing to different standards, increase understanding and facilitate comparisons of controller device interface standards.  Those requirements of the various controller device interface standards which can be considered as general have therefore been gathered in this part 1.
In addition to meeting the specific requirements stated in this part 1, the controller device interfaces included in this standard
   are documented in the English language in accordance with the requirements specified in this part 1,
   are already in use in commercial products and running in industrial plants,
   are available in quantity and at low price,
   are available from several sources and commercialised openly,
   to satisfy the tests specified, amongst others,  in EN 61000 4 2, EN 61000 4 3, EN 61000 4 4,
EN 61000 4 5, and EN 61000 4 6 against the test levels specified in EN 50082 2,
   have appropriate mechanisms for transmission error detection,
   are open, widely accepted, well documented, stable and support inter operability,
   are complete and describe the necessary interfaces in sufficient detail to enable error free implementation,
   are free of any restriction related to testing the implementation.
For each controller device interface only two documents are necessary to determine all requirements and tests:
   the general requirements of this standard, referred to as "part 1" in the relevant parts covering the various types of controller device interfaces;
   the relevant controller device interface standard hereinafter referred to as the "relevant controller device interface standard" or "controller device interface standard".
The solutions described in this standard have been used for many years by industry to solve application requirements involving low voltage switchgear and controlgear. They are characterised by:
   their ability to power connected devices directly from the network;
   their ability to operate in harsh environments typified by those encountered at the machine level by controls in industrial applications;
   usage of the sophisticated medium access rules of CAN which allows both organisation of traffic based on user assigned priorities and efficient resolution of occasional access conflict;
   a wide range of exchange services allowing precise tailoring of data exchange to the actual application needs as well as simultaneous distribution of data to a selected set of connected devices;
   their capability to simultaneously support data acquisition, diagnostics, messaging and
   programming/configuration as required, amongst others, for systems interfacing controllers to
low voltage switchgear and controlgear in industrial applications.
NOTE   The controller device interface standards currently part of this series are:
   EN 50325 2:  DeviceNet
   EN 50325 3:  Smart Distributed System (SDS)
   EN 50325-4: CANopen
   EN 50325-5 : Functional safety communication based on EN 50325-4

  • Standard
    14 pages
    English language
    sale 10% off
    e-Library read for
    1 day

IEC PAS 63256:2020(E) defines the broadband fieldbus specification AUTBUS. AUTBUS implements real-time, high reliability and deterministic transmission and application for both industrial fieldbus data and ISO/IEC/IEEE 8802-3 Ethernet data by shared medium bus.
This document explains the structure and content of AUTBUS, and describes the definition and specification of Physical Layer (PhL) protocol / service, Data-link Layer (DLL) protocol / service and Application Layer (AL) protocol / service of AUTBUS

  • Technical specification
    196 pages
    English language
    sale 15% off