Field device tool interface specification - Device Type Manager (DTM) Styleguide for common object model

IEC/TR 62453-61:2009(E), which is a technical report, explains the guidelines and rules for the implementation of a Device Type Manager (DTM) with regard to the user interface and its functions. These guidelines and rules are part of the FDT specification and are intended to ensure that all users are provided with clear and consistent user interface functions and features across DTM devices in a system.

General Information

Status
Published
Publication Date
17-Aug-2009
Current Stage
PPUB - Publication issued
Start Date
18-Aug-2009
Completion Date
15-Aug-2009
Ref Project

Relations

Technical report
IEC TR 62453-61:2009 - Field device tool interface specification - Device Type Manager (DTM) Styleguide for common object model
English language
33 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


IEC/TR 62453-61 ®
Edition 1.0 2009-08
TECHNICAL
REPORT
colour
inside
Field device tool (FDT) interface specification –
Part 61: Device Type Manager (DTM) Styleguide for common object model

IEC/TR 62453-61:2009(E)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or
IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC/TR 62453-61 ®
Edition 1.0 2009-08
TECHNICAL
REPORT
colour
inside
Field device tool (FDT) interface specification –
Part 61: Device Type Manager (DTM) Styleguide for common object model

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
V
ICS 25.040.40; 35.100.05; 35.110 ISBN 978-2-88910-718-6
– 2 – TR 62453-61 © IEC:2009(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6
1 Scope.7
2 Normative references .7
3 Terms, definitions, symbols, abbreviated terms and conventions .7
3.1 Terms and definitions .7
3.2 Symbols and abbreviated terms.7
3.3 Conventions .8
3.3.1 Data type names and references to data types .8
3.3.2 Vocabulary for requirements.8
3.3.3 Specific formatting.8
3.3.4 State machine diagrams .8
4 Principles for designing DTM user interfaces .8
5 Benefits from the FDT user’s point of view.9
6 Functions of a DTM .11
6.1 General .11
6.2 Function “Main operation”.11
6.3 Functions “Online Parameterize” and “Offline Parameterize” .12
7 DTM user interface.12
7.1 Objective.12
7.2 General behavior.12
7.2.1 General .12
7.2.2 GUI navigation.12
7.2.3 GUI resizeability .12
7.2.4 Display of information.12
7.3 Microsoft Active Accessibility.13
7.4 Appearance.13
7.4.1 General .13
7.4.2 DTM user interface categories.14
7.4.3 DTM user interface areas .15
7.5 Parameter handling .20
7.5.1 Representation within Application Area.20
7.5.2 Change of parameter values.20
7.5.3 Representation of parameters.22
8 Representation of DTM functions.24
9 DTM behavior.27
9.1 Close of user interface with modified parameter values .27
9.2 Data set .27
9.2.1 Parameter in multiple user interfaces.27
9.2.2 Locking mechanism .27
9.3 Online parameterization / data source: device .28
9.4 Offline parameterization / data source: data set.28
9.5 Error handling .29
9.6 Communication .29
9.7 Access rights.30
9.7.1 FDT actors and parameter classes .30

TR 62453-61 © IEC:2009(E) – 3 –
9.7.2 OEM login .30
9.8 Localization.30
9.9 Documentation .30
9.10 Installation and un-installation .31
Bibliography.33

Figure 1 – Part 61 of the IEC 62453 series .6
Figure 2 – Standard User Interface (SUI) .10
Figure 3 – Advanced User Interface (AUI).11
Figure 4 – Areas of an SUI.14
Figure 5 – Areas of an AUI.15
Figure 6 – State diagram: Continuous Check .21
Figure 7 – State diagram: One Time Check.22
Figure 8 – Parameter value and associated information .22

Table 1 – Contents of Identification Area .16
Table 2 – Contents of Action Area .17
Table 3 – Contents of Status Bar .18
Table 4 – Possible connection states .18
Table 5 – Possible data source states.19
Table 6 – Possible states of the instance data set.19
Table 7 – Possible device diagnostic states (see [1]) .19
Table 8 – Possible states of parameters .23
Table 9 – Display of inadmissible or wrong data .24
Table 10 – Representation of functions .25
Table 11 – Relation between user roles and parameter classes .30
Table 12 – Installation and un-installation .31

– 4 – TR 62453-61 © IEC:2009(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 61: Device Type Manager (DTM) Styleguide
for common object model
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC/TR 62453-61, which is a technical report, has been prepared by subcommittee 65E:
Devices and integration in enterprise systems, of IEC technical committee 65: Industrial-
process measurement, control and automation:
This part, in conjunction with the other parts of the first edition of the IEC 62453 series
cancels and replaces IEC/PAS 62453-1, IEC/PAS 62453-2, IEC/PAS 62453-3, IEC/PAS
62453-4 and IEC/PAS 62453-5 published in 2006, and constitutes a technical revision.

TR 62453-61 © IEC:2009(E) – 5 –
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
65E/72/DTR 65E/121/RVC
Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The list of all parts of the IEC 62453 series, under the general title Field Device Tool (FDT)
interface specification, can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The “colour inside” logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this publication using a colour printer.

– 6 – TR 62453-61 © IEC:2009(E)
INTRODUCTION
This technical report is a user interface design specification for developers of FDT (Field
Device Tool) components for Function Control and Data Access within a Client/Server
architecture. The technical report is a result of an analysis and design process to develop
standard interfaces to facilitate the development of components by multiple vendors that shall
interoperate seamlessly.
A device-specific software component, called DTM (Device Type Manager), is supplied by the
field device manufacturer with its device. The DTM is integrated into engineering tools via the
FDT interfaces defined in this specification. The approach to integration is in general open for
all kinds of fieldbusses and thus meets the requirements for integrating different kinds of
devices into heterogeneous control systems.
To ensure the consistent management of a plant-wide control and automation technology, it is
necessary to fully integrate fieldbusses, devices and sub-systems as a seamless part of a
wide range of automation tasks covering the whole automation life-cycle. This integration also
requires a consistent look and feel of device specific components.
Figure 1 shows how IEC/TR 62453-61 is aligned in the structure of the IEC 62453 series.
Part 61
DTM Styleguide
Part 41
Object Model
Integration Profile
Figure 1 – Part 61 of the IEC 62453 series

TR 62453-61 © IEC:2009(E) – 7 –
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 61: Device Type Manager (DTM) Styleguide
for common object model
1 Scope
IEC/TR 62453-61, which is a technical report, explains the guidelines and rules for the
implementation of a Device Type Manager (DTM) with regard to the user interface and its
functions. These guidelines and rules are part of the FDT specification and are intended to
ensure that all users are provided with clear and consistent user interface functions and
features across DTM devices in a system.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
IEC 62453-1:2009, Field Device Tool (FDT) interface specification – Part 1: Overview and
guidance
IEC 62453-2:2009, Field Device Tool (FDT) interface specification – Part 2: Concepts and
detailed description
IEC/TR 62453-41:2009, Field Device Tool (FDT) interface specification – Part 41: Object
model integration profile – Common object model
ISO/IEC 19501:2005, Information technology – Open Distributed Processing – Unified
Modeling Language (UML) Version 1.4.2
3 Terms, definitions, symbols, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62453-1,
IEC 62453-2, IEC/TR 62453-41 and the following apply.
3.1.1
screen reader
software application that provides additional output to users (e.g. text-to-sound, braille)
3.1.2
navigation tree
GUI element, which displays the navigation information by means of a tree (e.g. tree control)
3.2 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviations given in IEC 62453-1,
IEC 62453-2, IEC/TR 62453-41 and the following apply.
GUI Graphical User Interface
– 8 – TR 62453-61 © IEC:2009(E)
SUI Standard User Interface (a GUI layout defined in this document)
AUI Advanced User Interface (a GUI layout defined in this document)
CUI Composition User Interface (a GUI layout defined in this document)
MSAA Microsoft Active Accessibility
OEM Original Equipment Manufacturer

3.3 Conventions
3.3.1 Data type names and references to data types
The conventions for naming and referencing of data types are explained in IEC 62453-2,
Clause A.1
3.3.2 Vocabulary for requirements
The following expressions are used when specifying requirements.
Usage of “shall” or “mandatory” No exceptions allowed.
Usage of “should” or “recommended” Strong recommendation. It may make sense in special exceptional
cases to differ from the described behavior.
Usage of “can’ or “optional’ A DTM may provide the function or behavior depending on the task
and type of the DTM. If a function or behavior is provided, it shall
follow the style guide.
3.3.3 Specific formatting
The following formatting is used to describe specific context.
CAPITAL LETTERS Names of keys on the keyboard —for example, SHIFT, CTRL, or ALT.
[Button text] Button with the specified text.
Name of an XML element according to data type definition in IEC/TR 62453-41.

3.3.4 State machine diagrams
Syntax of the state machine diagrams in this document is defined in IEC 62453-1 and in
ISO/IEC 19501:2005.
4 Principles for designing DTM user interfaces
The design of GUIs for DTMs is based on the following general principles for user interface
design [4],[5]. These are recommendations for good engineering practice. For additional
fundamentals of user interface design, please see the available literature.
Visibility of system status
The system should always keep users informed about what is going on, through appropriate
feedback within an acceptable time limit.
Match between system and the real world
The system should speak the users' language with words, phrases and concepts familiar to
the user, rather than system-oriented terms. Follow real-world conventions, making
information appear in a natural and logical order.

TR 62453-61 © IEC:2009(E) – 9 –
User control and freedom
Users often choose system functions by mistake and need a clearly marked "emergency exit"
to leave the unwanted state without having to go through an extended dialogue. Support undo
and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the
same thing. Follow platform conventions.
Error prevention
A careful design which prevents a problem from occurring in the first place is even better than
good error messages.
Recognition rather than recall
Make objects, actions, and options visible. The user should not have to remember information
from one part of the dialogue to another. Instructions for use of the system should be visible
or easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators - unseen by the novice user - may often speed up the interaction for the expert
user so that the system can cater to both inexperienced and experienced users. Allow users
tailoring of frequent actions.
Aesthetic and minimalist design
Dialogue should not contain information which is irrelevant or rarely needed. Every extra unit
of information in a dialogue competes with the relevant units of information and diminishes
their relative visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the
problem, and constructively suggest a solution.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary
to provide help and documentation. Any such information should be easy to search, focus on
the user's task, list concrete steps to be carried out, and not be too large.
5 Benefits from the FDT user’s point of view
Using DTMs compliant with this style guide enables the user to operate more efficiently and
more safely. The user is able to parameterize and manage the data of devices from various
manufacturers in a uniform way. Therefore, the user is presented with a clearly structured
concept regardless of the manufacturer or the type of the device. Details or requirements for
developers of a DTM are given within the following clauses.
Guideline and rules are defined for
• uniform user guidance: DTM user interfaces are used and displayed in engineering
systems and stand alone tools in the same manner regardless of the device or DTM
manufacturer or communication protocol employed;
• uniform behavior of a DTM. This includes:
• persistent storage,
• behavior in multi-user environments,
• error handling;
• clear identification of the DTM and the assigned device;
• ensuring users will be updated on the status and the parameterization of the configuration
constantly. All changes of the configuration are marked;
• informing users, whether GUI input affects the device directly or the offline configuration;

– 10 – TR 62453-61 © IEC:2009(E)
• executing plausibility checks of the configuration on a lexical (e.g. only certain characters
are accepted), syntactical (e.g. a limited number of characters) and semantically (e.g.
given value is below upper limit) correct basis;
• uniform installation/un-installation procedure.
The following screen shots show a Standard User Interface (SUI) (see Figure 2) and an
Advanced User Interface (AUI) (Figure 3), two of three possible user interface types (see
7.4.2).
Figure 2 – Standard User Interface (SUI)

TR 62453-61 © IEC:2009(E) – 11 –

Figure 3 – Advanced User Interface (AUI)
6 Functions of a DTM
6.1 General
According to IEC/TR 62453-41, a DTM exposes the complete set of available functions with
respect to the current state within the XML document returned by IDtm:GetFunctions(). The
Frame Application (FA) is responsible for presenting these functions within its overall user
interface in a homogeneous way. There should be no break between the DTM based functions
and the FDT Frame Application functions.
In general, the Frame Application is responsible for identifying the DTM instance and starting
the current function performed by the DTM instance. Such a function can be handled by a
specific user interface provided by the DTM. In this case, the Frame Application starts this
DTM user interface as integrated application. The Frame Application then shows identification
information in a window title bar of this application.
See IEC 62453-2 for a list of predefined applicationIds (Table A.2). Clause 5 in IEC 62453-2
provides information on use cases related to the predefined applicationIds.
6.2 Function “Main operation”
A DTM can have a ‘main operation’ function. This is a special application which aggregates all
DTM user interfaces. When ‘main operation’ is started, it shall show a GUI which identifies the
device (ie. user interface of application ‘fdtIdentify’).
For providing ‘main operation’ an fdt:StandardFunction entry shall be used with the
fdt:applicationId ‘fdtMainOperation’. If ’main operation’ cannot be assigned to an applicationId,
an fdt:Function entry shall be provided (see IEC 62453-2, Table A.13).

– 12 – TR 62453-61 © IEC:2009(E)
6.3 Functions “Online Parameterize” and “Offline Parameterize”
A DTM that allows changing the parameter of a device should provide fdt:StandardFunction
for parameterization (applicationIds “fdtOfflineParameterize” and “fdtOnlineParameterize”).
If a DTM offers user interfaces for configuration or parameterization, it shall be possible to
use these applications offline as well as online. This means configuration or parameterization
shall be possible without a connected device.
7 DTM user interface
7.1 Objective
The user interface of a DTM application shall be designed to provide the user with a software
component that is easy to use and self-explanatory. The user interface assists the user to be
able to concentrate on his main tasks. The user should not be detracted by novel user
interface elements or features.
7.2 General behavior
7.2.1 General
The user interface of a DTM should be based on the Microsoft Windows Style Guide ([3]). It is
recommended to use Windows common controls. Windows common controls shall act in the
way defined by Microsoft. That means, it is not allowed to change the behavior of common
controls like buttons, combo boxes, edit controls, keyboard shortcuts etc.
7.2.2 GUI navigation
Elements of the DTM user interface shall be selectable by a pointing device (e.g. mouse) and
with keyboard. The keyboard shortcuts for navigation among GUI areas and objects shall be
supported. TAB-key and SHIFT-TAB combination is used for navigation between Application
Area, Action Area and optional Navigation Area. The navigation between objects in
Application Area shall be possible also with the same shortcuts. The TAB-order of elements
within the Application Area is from upper left to lower right corner, at least for languages that
are written from left to right. Middle Eastern languages such as Hebrew and Arabic are written
predominantly right-to-left. Consequently, Middle Eastern user interfaces require a different
layout. The focus shall change to another area, if the TAB-key is pressed on the last element
of the current area. Navigation within a tree view shall be possible with arrow keys.
7.2.3 GUI resizeability
A DTM user interface should be implemented in a resizable way. In this case, the DTM is
responsible for supporting re-arrangement of the inner controls. If the initial minimum size is
reached, the DTM shall not implement scroll bars because the Frame Application is
responsible for that.
7.2.4 Display of information
The display of any information in a visual user interface is accomplished in a textual, symbolic
or graphic manner.
Only one font family should be used to optimize the readability of texts (system font is
recommended). Only a minimum variation of the font size and font style should be used.
7.4.3.7.2,
Icons defined in this style guide shall be used only in the defined meaning (see
7.4.3.8 and 7.5.3.2). Icons used in addition to the defined icons should be plain and
unambiguous and oriented towards existing specifications (e.g. operation system common
icons). Tool tips are mandatory for all used icons.

TR 62453-61 © IEC:2009(E) – 13 –
Color shall only be used as secondary information. The color set should be kept small.
Flashing information should not be used as a further display attribute. In general, a DTM
should use the style chosen within the user settings of the operating system (i.e. Windows).
The currently used color scheme should be explained in the online documentation of the DTM.
All definitions and descriptions inside this Style Guide are related to “left-to-right” languages.
Middle Eastern languages such as Hebrew and Arabic are written predominantly right-to-left.
Consequently, Middle Eastern user interfaces require an adapted layout.
7.3 Microsoft Active Accessibility
Microsoft Active Accessibility (MSAA) [6] is a technology designed to improve the integration
of accessibility aids with applications running on Microsoft Windows. MSAA provides a
consistent mechanism for exchanging information between applications and assistive
technologies. For example, MSAA allows applications to expose screen readers to the type,
name, location, and current state of all objects and notifies screen readers of any Windows
event that leads to a user interface change.
As a side effect it is possible to use MSAA for fully automated tests of component based
software systems. Therefore, a DTM should support MSAA.
User interfaces built with Microsoft common controls typically get full Active Accessibility
support without additional development work. However, special attention shall be given if
DTM specific user interface controls are used. DTM developers should always verify that
these controls are compliant to Active Accessibility requirements.
Basic Principles of Accessible Design
Although, no additional development work is required to support Active Accessibility in many
cases, the user interface should always be designed with respect to the following five
principles:
• support common system size, color, font, and input settings. This provides a consistent
user interface across all applications on the user's system;
• ensure compatibility with the High Contrast option. Users desiring a high degree of
legibility select the High Contrast option. When this option is selected several restrictions
are imposed upon the user interface. For example, only system colors selectable through
the Control Panel or colors set by the user may be used by the user interface;
• provide documented keyboard access to all features. This allows the user to interact with
the application without requiring a pointing device, such as a mouse;
• provide notification regarding the location of the keyboard focus (i.e. which element
receives keyboard input). It should always be apparent to the user and programmatically
which part of the user interface has the focus. This requirement also enables use of the
Magnifier and Narrator accessibility aids;
• convey no information by sound alone. User interfaces that convey information by sound
shall provide additional options to express this information.
7.4 Appearance
7.4.1 General
Three categories of DTM user interfaces are specified:
– standard layout, where one presentation object displays one application with no or only
with limited navigation capability;
– advanced layout, where one presentation object displays one application with advanced
navigation capability;
– 14 – TR 62453-61 © IEC:2009(E)
– composite layout, where one presentation object displays multiple applications (for
different DTM functions) with advanced navigation capability. The navigation capability
also is used for switching between the different applications.
7.4.2 DTM user interface categories
In general, a DTM user interface is divided into the following areas:
• Identification Area: contains information about the device that is handled by the DTM;
• Application Area: contains all necessary GUI elements for the selected function;
• Action Area: contains buttons to initiate the user’s choice,
• Status Bar: contains global status information about the DTM and device.
These areas shall be arranged as described in the following sections.
7.4.2.1 Standard User Interface (SUI)
Figure 4 shows the areas for the SUI of a DTM.
Identification Area
1)
Menu
1)
Toolbar
Application Area
Action Area
Status Bar
Key
1) Optional areas
Figure 4 – Areas of an SUI
Additional to the mandatory elements (Identification Area, Application Area, Action Area and
Status Bar) the GUI may contain a tool bar and/or a menu.
7.4.2.2 Advanced User Interface (AUI)
Depending on the complexity of a device and the required functionality, the DTM user
interface additionally may provide navigation (see Figure 5).
Such a GUI shall be conform to the AUI layout and provide a Navigation Area.
The Navigation Area provides an overview of the whole parameter set that is related to the
current function. In other words, the Navigation Area reflects the data structure. The
Navigation Area shall be realized as a navigation tree.

TR 62453-61 © IEC:2009(E) – 15 –
Identification Area
Menu 1)
Toolbar 1)
Navigation Area Application Area

Action Area
Status Bar
Key
1) Optional areas
Figure 5 – Areas of an AUI
Additional to the mandatory elements (Identification Area, Navigation Area, Application Area,
Action Area and Status Bar) the GUI may contain a tool bar and/or a menu.
7.4.2.3 Composition User Interface (CUI)
The CUI provides access to multiple applications and DTM functions. The user interface is
identified with applicationId ‘fdtMainOperation’ (see 6.2)
The CUI contains the same elements as the AUI.
In contrast to the AUI, the navigation tree shows all integrated applications of the DTM, for
example parameterization, diagnosis or device status together with related parameter groups.
The left most nodes of the navigation tree shall represent the different DTM applications. All
sublevel nodes reflect the structure of data for each application.
7.4.3 DTM user interface areas
7.4.3.1 General
In general, the user must be aware if modifications of parameters are applied into the data set
of the DTM or into the device. Also the behavior of the GUI may vary depending on whether
the GUI supports block mode (see 7.5.2.2) or direct mode (see 7.5.2.3).
7.4.3.2 Identification Area
This area contains information about the device that is handled by the DTM (see Table 1).

– 16 – TR 62453-61 © IEC:2009(E)
Table 1 – Contents of Identification Area
Height Width Contents (read only) Availability
Maximal 3 Variable Device picture (left side) Recommended
text lines
Company logo of the device manufacturer (right side, optional Recommended
home page link: use company logo to directly open a web
page in an internet browser)
Between picture and logo:
1st line: Device: name attribute of fdt:VersionInformation Mandatory
from DtmDeviceType
2nd line: Description: Description according [2] Recommended
3rd line: DTM specific line (Can be fetched from the Optional
device, too)
7.4.3.3 Menu (optional)
This optional area shall be used only in special cases.
The menu shall contain only menu entries which are directly related to the Application Area.
That means if application A is opened within the Application Area the menu shall not contain
menu entries of application B.
In a CUI menu entries relating to more than one specific application can also be available.
The selection of such a menu item opens the related application within the Application Area.
7.4.3.4 Tool bar (optional)
This optional area shall be used only in special cases.
The tool bar shall contain only elements which are directly related to the Application Area.
In CUI additional entries relating to more than one specific application may be available.
Also a [Help] button could be part of the tool bar.
7.4.3.5 Navigation Area (conditional)
The Navigation Area is used only in AUI or CUI.
The Navigation Area contains a navigation tree. This tree provides an overview of the whole
parameter set. Within the tree the parameter set shall be grouped to appropriate parameter
groups.
When selecting a navigation tree entry (leaf or branch) the corresponding parameter group
shall be displayed in the Application Area.
The Navigation Area may be hidden or resizable and it can contain scroll bars .
Within a CUI the Navigation Area is also used for selecting different applications. Two
approaches are possible:
a) displaying the applications as left most nodes in the navigation tree (see 7.4.2.3);

TR 62453-61 © IEC:2009(E) – 17 –
b) the Navigation Area can have several tab cards with a tree. Each tab card provides a
different view on the same parameters. The tab cards shall be organized according to the
users needs. The left most shall be the view relating to applications.
7.4.3.6 Application Area
The content of this area depends on the selected application. When the application allows
handling of parameters see 7.5 for additional details.
7.4.3.7 Action Area
The content of this area depends on the application type as described in the following
chapters.
7.4.3.7.1 Application without changeable values
The Action Area contains only a [Close] button. Activation of this button closes the DTM user
interface.
7.4.3.7.2 Application with changeable values
The area contains the following buttons in the described order.
[Ok] [Cancel] [Apply]
The button texts shall be adapted to the configured language according to the texts used in
standard Microsoft Windows application. The [Ok] and [Apply] buttons will be applied
regarding the data source which currently is shown in the status bar (see Table 2).
Table 2 – Contents of Action Area
Button Data source Behaviour
[Ok]
Values changed in user interface will be applied on the instance data set, only. The

user interface will be closed (e.g.offline parameterize)
[Ok] All changed values will be transmitted to the device, only. The attribute

(DtmParameterSchema) shall be set. The user interface will be
closed (e.g.online parameterize)
[Ok] Applications contain values from different data sources. Each value of the application

itself shall be uniquely assigned to one data source by an appropriate icon (see
Table 5). Based on this icon a changed value will be applied on the instance data set
or will be transmitted to the device.The user interface will be closed (e.g. online
compare)
[Cancel] All states In general, changed values will NOT be applied. Application will be closed. Please see
also 7.2
[Apply] Same behavior as [Ok], but application will NOT be closed

[Apply] Same behavior as [Ok], but application will NOT be closed

[Apply] Same behavior as [Ok], but application will NOT be closed

In a CUI it may be necessary to change the contents of the action area, according to the
selected application. In case of switching from applications with changeable values to an
application with non-changeable values the DTM shall behave as defined in 9.1.
7.4.3.8 Status Bar
The Status Bar contains global status information about the DTM and the device.

– 18 – TR 62453-61 © IEC:2009(E)
Elements of the Status Bar are listed in the following table (Table 3) and are displayed from
left to right.
Table 3 – Contents of Status Bar
Height Width Contents (read only) Icon Availability
1 text line Variable 1. DTM connection state See Table 4 – Possible Mandatory
connection states
2. Communication in progress Mandatory

3. Data Source See Table 5 – Possible Mandatory
data source states (for
icon and text)
4. State of instance data set See Table 6 – Possible Mandatory
(AllDataLoaded, validModified, states of the instance
invalidModified) data set (for Icon and
text)
5. Changes directly made on the device. Mandatory

Changes have only an impact on the
(combined icon ‘valid
device and not on the instance data set
(see use case Online Parameterization). modified’ and ‘device’)
Instance data set and device may not be
consistent any longer.
Status of attribute ‘modifiedInDevice’ shall
be shown as specified in IEC/TR 62453-
41. This display shall be provided even if
the attribute is not supported in the
parameter document of the DTM
6. Direct mode active Mandatory

7. Device diagnosis status. according See Table 7 – Possible Optional
NAMUR, see [1] (icons with tool tips) device diagnostic states
(see [1])
8. OEM Login or User role (refer also to ’No user logged in’ or Optional
Table 12: relation between user roles and name of the user who is
parameter classes) logged in
9. Progress bar Optional
Possible connection states are given in Table 4 below.
Table 4 – Possible connection states
Icon Text (English) Meaning DTM state Availability
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...