Upload
phungnhi
View
237
Download
1
Embed Size (px)
Citation preview
Deleproject AG
Industriestrasse 12 Postfach 70 CH-3661 Uetendorf/Thun www.deleproject.ch
Automation Design Toolkit Software Requirements Specification
Master-Thesis
Number MAS-06-02.11
Class MAS-IT 06-02
Student Björn Krebser, Deleproject AG, [email protected], +41 (33) 346 60 29
Advisor Bernhard Hunziker, Deleproject AG, [email protected], +41 (33) 346 60 10
Expert Rolf Wenger, INFOBRAIN AG, [email protected], +41 (31) 544 22 22
Keywords Plug-In, Design Tool, Script/Template Language
Document Information
Authors bk Björn Krebser (Deleproject AG)
File MAS-06-02.11-ADT-RequirementsSpecification-1.0.6.docx
Saved Thursday, 13 November 2008
Printed Thursday, 13 November 2008
Abstract
The purpose of the present Master-Thesis is to build an adaptable design and documentation toolkit
for automation systems, using an existing client-server platform that is built on C# and the .NET
framework.
Deleproject AG
Industriestrasse 12 Postfach 70 CH-3661 Uetendorf/Thun www.deleproject.ch
Version History
Version Date Author Description
1.0.6 13.11.2008 bk Finalization, Corrections
1.0.5 06.11.2008 bk Changes after 1st review with expert: - All detailed functional and technical requirements
have been moved into a draft version of the software design description
1.0.4 30.10.2008 bk 1st printable version
Requirement modifications are noted in the history summaries within each chapter.
Automation Design Toolkit Intro Software Requirements Specification
Page I
Index of Contents
1 Preface 1
1.1 The Background of the Project Effort 1
1.2 Goals of the Project 1
1.3 Releases 1
1.4 The Scope of the Product 2
1.5 The Scope of the Work 2
1.6 Stakeholders 2
1.6.1 Client 2
1.6.2 Customer 3
1.6.3 Other Stakeholders 3
1.7 Similar Products 3
1.8 Terms and Abbreviations 3
1.9 User Characteristics 3
1.9.1 User 3
1.9.2 Administrator 3
1.10 Realisation 4
1.10.1 Road Map 4
1.10.2 Iterations 4
1.10.3 Movable Components 4
1.11 Constraints 4
1.11.1 Technical Constraints 4
1.11.2 Organisational Constraints 5
1.11.3 Process Constraints 5
1.11.4 History 5
1.12 Project Plan 6
1.13 Dependencies and Assumptions 6
2 Functional Requirements 7
2.1 Requirements List 7
2.1.1 History 7
2.2 Graphical User Interfaces (GUI) 7
2.2.1 Introduction 7
2.2.2 Functional Requirements 7
2.3 Automation System Model Design (ModDes) 8
2.3.1 Introduction 8
2.3.2 Associated Functional Requirements 9
2.4 Module Interface Definition (ModIntf) 9
2.4.1 Introduction 9
2.4.2 Associated Functional Requirements 9
2.5 Module State Machine Definition (StMaDef) 10
2.5.1 Introduction 10
2.5.2 Associated Functional Requirements 10
Automation Design Toolkit Intro Software Requirements Specification
Page II
2.6 Plug In Handling (PlugInHndl) 11
2.6.1 Introduction 11
2.6.2 Associated Functional Requirements 11
2.7 Export Plug-Ins (ExpPlugIn) 12
2.7.1 Introduction 12
2.7.2 Associated Functional Requirements 12
2.8 Import Plug-Ins (ImpPlugIn) 13
2.8.1 Introduction 13
2.8.2 Associated Functional Requirements 13
3 Non Functional Requirements 15
3.1 Quantity Structure 15
3.2 Non Relevant Requirements 15
3.3 Reliability 15
3.4 Adaptability 16
3.5 Internationalisation 16
Appendix A - Description of the Software Design Platform 17
A.1 Overview 17
A.2 Features 17
A.3 System Interfaces 17
Appendix B - Standards and Products 18
B.1 Standard: ANSI/ISA S88 18
B.1.1 Brief Description 18
B.1.2 S88 Physical Model 19
B.1.3 S88 Procedural Control Model 19
B.1.4 Relationships 20
B.1.5 S88 State Transition Diagram of Procedural Elements 21
B.2 Product: Rockwell RSLogix5000 21
B.2.1 Brief Description 21
B.2.2 Project Data 22
B.2.3 Import/Export from/to L5K file 22
B.2.4 Import/Export from/to CSV file 22
B.2.5 Import/Export from/to L5X file 23
B.3 Product: Siemens STEP7 23
B.3.1 Brief Description 23
B.3.2 Project Data 23
B.3.3 Import/Export using STL sources 23
B.4 Product: Wonderware Industrial Application Server 24
B.4.1 Brief Description 24
B.4.2 Project Data 24
B.4.3 Import/Export Objects 24
B.5 Product: Wonderware InTouch HMI 25
B.5.1 Brief Description 25
B.5.2 Import/Export Tag Definitions 25
Automation Design Toolkit Intro Software Requirements Specification
Page III
Appendix C - Glossary 26
C.1 A ... E 26
C.2 F ... I 27
C.3 J ... N 27
C.4 M ... S 28
C.5 T ... Z 29
Appendix D - Literature 30
Index of Figures
Figure 1-1 Scope of the Product 2
Figure 1-2 Project Plan 6
Figure 2-1 Module Types and Logical Modules 8
Index of Tables
Table 1-1 Technical Constraints 4
Table 1-2 Organisational Constraints 5
Table 1-3 Process Constraints 5
Table 2-1 Requirements List 7
Automation Design Toolkit Preface Software Requirements Specification
Page 1
1 Preface
1.1 The Background of the Project Effort Currently the development of automation systems has to be done using several tools from different
companies. Each of these tools has its own project data format and storage system and mostly only
few documentation functionalities. Most of the implementation and documentation work needs to
be done by hand without code generation or forward / reverse engineering possibilities.
There is a big potential to link these tools together using a system that is able to design, generate and
document parts of the relevant data/objects.
1.2 Goals of the Project The project Automation Design Toolkit has to build a system that can be used for design, modelling
and documentation purposes of automation projects.
The project covers these main features:
- The development work of medium and big automation projects should be performed by a team
of developers.
- The main data of automation projects should be handled in a centralised data base.
- The implementation time and costs within automation projects should be reduced.
- The developers should be able to use the system in the office and outwards during offline work
and commissioning. A user should be able to synchronize his offline changes when he comes
back to the office.
1.3 Releases The entire project is split into three releases.
1st release
The 1st release, called Software Design Platform, includes a client server architecture in which
automation systems can be handled by project teams.
More details about the Software Design Platform are described in Appendix A - Description of the
Software Design Platform.
2nd release
The present (2nd) release has to be implemented using the functionality of the Software Design
Platform. The present requirement specification covers the functionality of the 2nd release.
3rd release
This 3rd release includes all functionalities that are postponed from the previous releases.
Automation Design Toolkit Preface Software Requirements Specification
Page 2
1.4 The Scope of the Product The following figure shows the scopes of the end product Automation Design Toolkit, all parts that
have to be done in the scope of the work (2nd release) and the base functionality of the existing
Software Design Platform (1st release).
Automation Design Toolkit
Software Design Platform (1st Release)
Data Access, Data Handling and Distribution
Data Base
Management of Automation Systems /
Repository
Future Extension
Scope of the end product
User Handling / Change Traceablilty
Management of Module Types and Instances
Plug In Handling / Runtime Engine
Additional DB
Objects
Plug Ins
Type
DefintionsScope of the work /
2nd release
Scope of the 1st release (Existing)
Plug InsPlug Ins
Plug InsPlug InsPlug InsPossible future
extensions
DB Objects
.NET Framework System Interfaces
Figure 1-1 Scope of the Product
1.5 The Scope of the Work The scope of the work includes the requirements analysis, design, implementation and integration
testing of the present (2nd) release further called as the System.
1.6 Stakeholders
1.6.1 Client The client is the company Deleproject AG located in Uetendorf/Thun, Switzerland. The involved
employees are:
Name Function in this Project
Björn Krebser Project Leader
Bernhard Hunziker Technical Consultant
Automation Design Toolkit Preface Software Requirements Specification
Page 3
1.6.2 Customer There are no customers involved at this time.
1.6.3 Other Stakeholders There are no other stakeholders defined at this time.
1.7 Similar Products The following products include some features of the Automation Design Toolkit. They helped to find
some ideas and were a good source for inspirations.
Subversion [SUB01]
Features: Versioning, check in and checkout principles
Wonderware Industrial Application Server [IAS01]
Features: Module types definitions, handling of derived objects, check in and checkout principles
Enterprise Architect [EA01]
Features: Code forward and reverse engineering, template language to adapt documentation or code generation
1.8 Terms and Abbreviations All used terms and abbreviations in this document are explained in the Appendix C - Glossary.
1.9 User Characteristics The system has to be used by peoples of two characteristics. The user characteristic is given by the
host on which a user is working. The user characteristics are handled by the Software Design
Platform.
1.9.1 User A person that uses the Client-Host has User characteristics. The User represents a software engineer
who is developing an automation system. In general he has good knowledge of software tools. All
requirements in the present release are related to Users.
1.9.2 Administrator A person that uses the Server-Host has Administrator characteristics. The Administrator represents a
system specialist that is able to do maintenance of server operating systems. The Administrator is not
involved by the requirements of the present release
Automation Design Toolkit Preface Software Requirements Specification
Page 4
1.10 Realisation It's planned that the realisation of the end product will be done by three main releases:
1.10.1 Road Map Finished before: Notes
1st release January 2009
2nd release 19th of February 2009 Fixed date from the Master Thesis time plan
3rd release May 2009
1.10.2 Iterations The present release has to be realized by maximum three iterations. Each iteration has to cover the
analysis, design, implementation and testing of the related requirements. Each iteration ends with an
integration-test.
1.10.3 Movable Components All moveable components will be added to the requirements specification of the 3rd release.
1.11 Constraints
1.11.1 Technical Constraints All technical constraints are given by the Software Design Platform and are not covered by this
document.
Constraint Description
Hardware Infrastructure Intranet / Internet networks have to be supported
Software Infrastructure The system has to run of the current Windows operating systems as XP, Vista, 2003/2008 Server.
Operating Modes Online / Offline
Runtime Availability During normal working times
Graphical user interface Modern look and feel using Windows Presentation Foundation technology of the .NET Framework
Libraries, Frameworks Common Application Services from Deleproject .NET Framework 3.5 SP1 from Microsoft
Programming languages C#
Data storage The data base product [FireBird] has to be used for the data storage layer. Data Base Version: 2.1, .NET Data Provider Version: 2.0.1
Programming guidelines Naming conventions [CodeStyle]
Operating systems .NET 3.5 compatible windows based OS
Table 1-1 Technical Constraints
Automation Design Toolkit Preface Software Requirements Specification
Page 5
1.11.2 Organisational Constraints Constraint Description
Project organisation One Project Leader without additional resources.
Client organisation Not applicable.
Development of a saleable product or internal use
Has to be designed for internal use
Table 1-2 Organisational Constraints
1.11.3 Process Constraints Constraint Description
Process Model The project has to be done by using an OpenUP process model that has been specified by Deleproject, [DevProc01]
Table 1-3 Process Constraints
1.11.4 History Version Date Author Modifications
1.0.0 21.10.08 bk 1st release
Automation Design Toolkit Preface Software Requirements Specification
Page 6
1.12 Project Plan The following project plan is a snapshot at that time when the requirements document is released.
The actual project plan is included in a separate document that can be changed during the project
lifetime.
Figure 1-2 Project Plan
1.13 Dependencies and Assumptions No additional dependencies and assumptions.
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 7
2 Functional Requirements
2.1 Requirements List Summary of all functional requirements that are covered by the 2nd release:
Requirement-ID Description Chapter
GUI Graphical User Interface 2.2
ModDes Automation System Model Design 2.3
ModIntf Module Interface Definition 2.4
StMaDef Module State Machine Definition 2.5
PlugInHndl Plug In Handling 2.6
ExpPlugIn Export Plug-Ins 0
ImpPlugIn Import Plug-Ins 2.8
Table 2-1 Requirements List
2.1.1 History This history covers only changes on the requirements list above.
Version Date Author Modifications
1.0.3 27.10.08 bk 1st version
2.2 Graphical User Interfaces (GUI)
2.2.1 Introduction The user interface is the main system component that a user is working with. It has a big influence on
the overall system appealing and acceptance.
The technical constrains are covering which technology and framework has to be used for the
development of the user interface.
The following functional requirements cover the look and feel of the user interface from the end
users point of view.
2.2.2 Functional Requirements ID Priority Description
10 2 The system should provide the look and feel of the user interface that follows a modern style.
20 1 The system shall ensure that all user controls with a specific functionality like a Close button always have the same name and icon.
2.2.2.1 History
1.0.4 30.10.08 bk 1st version
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 8
2.3 Automation System Model Design (ModDes)
2.3.1 Introduction In the process industry an automation system usually consists of a physical and procedural model of
one more areas including units, sub-units and components, following the ANSI/ISA S88 standard. The
system has to provide the ability to design ANSI/ISA S88 based physical und procedural models
within automation systems.
More details about the ANSI/ISA S88 standard can be found in appendix B.1.
2.3.1.1 Module Types
The following figure shows the mapping of the elements from the S88 models into module types and
logical modules:
Structural Modules
Area
Process Cell
Unit
Functional Modules
Equipment Module
Control Module
Procedure
Unit Procedure
Operation
Phase
S88 Physical Model S88 Procedural Control Model
Permanent Logic Module Sequential Logic Module
&
&
Figure 2-1 Module Types and Logical Modules
A structural module represents an asset (an area, process cell or unit) within the S88 physical model.
It can define a naming convention or global prefix for its contained modules. An asset does not
include any functional logic.
A functional module represents an asset within the S88 physical model (an equipment module or
control module) or within the S88 procedural control model (a procedure, unit procedure, operation,
or phase). It contains functional logic that is one of the following types of logic modules:
A sequential logic module consists of one or multiple sequential logic parts. Each part will be
executed by the PLC based on a specific state of the module. Therefore a sequential logic module
contains an internal state machine and an interface. The interface is used to interact with the module
or to know its state.
A permanent logic module consists of one or multiple permanent logic parts. Each part will be
executed by the PLC based on a specific state of the module. Therefore a permanent logic module
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 9
contains an internal state machine and an interface. The interface is used to interact with the module
or to know its state. A permanent logic module is used mainly as a black box that hides the internal
functionality that will be implemented by the PLC.
2.3.1.2 Module Types and Instances
A module type defines the common structure and behaviour of a functional module. A module type
can be based on another module type.
A module instance is based on a module type or a functional or structural module.
2.3.2 Associated Functional Requirements ID Priority Description
10 1 The system shall visualize the user an editable tree (the type view) that shows all functional module types within an automation system
11 1 The system shall visualize the user an editable tree (the instance view) that shows all instances of structural and functional module within an automation system
20 1 The system shall provide the user the ability to create new module types in an automation system
21 1 The system shall provide the user the ability to create new instances of structural or functional modules in an automation system.
30 1 The system shall provide the user the ability to modify and remove a module type.
31 1 The system shall provide the user the ability to modify and remove a module instance.
40 1 The system shall provide the user the possibility to cancel the editing processes Create, Modify and Delete of a module type or instance.
History
1.0.5 06.11.08 bk 1st version
2.4 Module Interface Definition (ModIntf)
2.4.1 Introduction Functional modules require an interface to be able to interact with other modules. An interface
consists of multiple interface signals.
An interface signal can represent an input, parameter, output, transit signal or an operation. Some
data of interface signals that are defined in a functional module type can be set by module instances.
Each interface signal is based on a specific data type which is provided by the automation system.
2.4.2 Associated Functional Requirements ID Priority Description
10 1 The system shall be able to visualize the user an editable list showing all data fields of all interface signals of a functional module.
20 1 The system shall provide the user the ability to add a new interface signal to a functional module.
21 1 The system shall provide the user the ability to modify and remove interface signals.
22 3 The system shall provide the user the ability to add, modify and remove interface signals of a functional module that is derived from another module type.
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 10
23 2 The system shall provide the user the ability to add data to an interface signal in a module instance.
30 1 The system shall provide the user the possibility to cancel the editing processes Create, Modify and Delete of an interface signal.
History
1.0.6 12.11.08 bk Data type definition moved to the 1st release
1.0.0 25.10.08 bk 1st version
2.5 Module State Machine Definition (StMaDef)
2.5.1 Introduction The purpose of this requirement is to use the system to define state machines within functional
modules. The system will be used to design and document state machines and to generate most of
the specific functionality of a state machine. The common functionality of a state machine will be
implemented in the PLC.
A state machine usually covers the main functionality inside of a functional module. Usually such a
state machine has a structure related to the S88 State Transition Diagram, described in appendix
B.1.5. In principal the functional module type defines the common structure of a state machine and
all instances that are based on this functional module type define the contents of the state machine.
A step has a number in a range that is defined by the transient state. A step can have some
associated actions which are executed as long the step is active. A step is active until one outgoing
transition is fulfilled. The sequencer changes to a step when its incoming transition is fulfilled. A step
can have one or multiple timers that run as long a step is active. These timers can be used as an
outgoing condition when the timer has been elapsed.
An action is part of a step or a state. An action is used to interact with the interface of a module
instance. (Examples: Start a motor, set a parameter to 10°C...)
A condition compares two values and can be combined by one or multiple groups of logical AND / OR
interconnections.
A transition consists of one or multiple conditions. The transition changes to the defined destination
if the logical interconnection of the conditions is fulfilled.
2.5.2 Associated Functional Requirements ID Priority Description
10 1 The system shall visualize the user an editable tree that shows a state machine and all its contents within a functional module type or instance
11 2 The system shall visualize the user an editable tree of a sequencer and its contents within a transient state of a state machine
12 2 The system shall visualize the user the steps with all their conditions and actions of a transient state.
20 1 The system shall provide the user the ability to create a common state machine in a functional module type.
21 1 The system shall provide the user the ability to extend a common state machine that has been defined by the functional module type, within a module instance.
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 11
22 1 The system shall provide the user the ability to delete a state machine of a functional module type.
30 2 The system shall provide the user the ability to add, modify and remove new states, transitions and conditions to a state machine.
31 2 The system shall provide the user the ability to add, modify and remove steps to a transient state.
32 2 The system shall provide the user the ability to move or clone a step and all its contents within the same functional module.
33 2 The system shall provide the user the ability to add, modify and remove step actions, step transitions and step timers to a step.
40 1 The system shall provide the user the possibility to cancel the editing processes Create, Modify and Delete of a state machine and its contents.
History
1.0.0 25.10.08 bk 1st version
2.6 Plug In Handling (PlugInHndl)
2.6.1 Introduction The system hosts Client and Server of the software design platform shall be extended using plug-ins.
A system host should be able to use the following types of plug-ins:
Editing Plug-In
A data editing plug-in will be used to extend the data editing behaviour. This type of plug-in will be
implemented in the 3rd release.
Import Plug-In
An import plug-in will be used to import data into the system.
Export Plug-In
An export plug-in will be used to export data from the system.
2.6.2 Associated Functional Requirements ID Priority Description
10 1 The system has to provide the user the ability to use plug-ins within the Client Host.
11 1 The system shall be able to detect invalid or wrong versioned plug-ins and show them to the user in form of an error message.
12 1 The system shall provide the user a list where the user can select a plug-in.
History
1.0.3 27.10.08 bk 1st version
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 12
2.7 Export Plug-Ins (ExpPlugIn)
2.7.1 Introduction The purpose of this requirement is to use several plug-ins that exports module instance data to one
or multiple text formatted files. The content and format of the text files can differ in each concrete
plug-in.
An export plug-in can cover one or multiple data formats like a list, a logical block, a document... that
has to be generated.
2.7.2 Associated Functional Requirements
2.7.2.1 Common
These requirements are valid for all export plug-ins.
ID Priority Description
10 2 The system shall provide the user the ability to select an automation system or a set of module instances that have to be used by an export plug-in.
11 2 The system shall provide the user the ability to select an export plug-in which has to be used with the selected data.
History
1.0.3 27.10.08 bk 1st version
2.7.2.2 Export Plug-In for RSLogix5000
This plug-in has to be used to export module instance data into a L5K or CSV file that can be imported
by the RSLogix5000 software from Rockwell Software.
See appendix B.2 for more information's about RSLogix5000.
ID Priority Description
20 2 The plug-in shall be able to generate a CSV file that contains controller tags based on the data of multiple module instances and types
21 2 The plug-in shall be able to generate a L5K file that contains calls and mappings of multiple functional module instances
22 3 The plug-in shall be able to generate a L5K file that contains the implementation of a functional module and its state machine
History
1.0.3 27.10.08 bk 1st version
2.7.2.3 Export Plug-In for Step7
This plug-in has to be used to export module instance data into an STL source that can be imported
by the STEP7 software from Siemens
See appendix B.3 for more information's about STEP7.
ID Priority Description
30 3 The plug-in shall be able to generate an STL source that contains data blocks (DBs) based on the data of multiple module instances and types
31 3 The plug-in shall be able to generate an STL source that contains calls and mappings of multiple functional module instances
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 13
History
1.0.6 12.11.08 bk New plug-in
2.7.2.4 Export Plug-In for InTouch
This plug-in has to be used to export module instance data into a CSV file that can be imported by the
InTouch HMI software from Wonderware.
See appendix B.5 for more information's about InTouch HMI.
ID Priority Description
40 2 The plug-in shall be able to generate a CSV file that contains tag definitions based on the data of multiple module instances and types
History
1.0.6 12.11.08 bk New plug-in
2.7.2.5 Export Plug-In for IAS
This plug-in has to be used to export module instance data into a CSV file that can be imported by the
Industrial Application Server software from Wonderware.
See appendix B.4 for more information's about the Industrial Application Server.
ID Priority Description
50 2 The plug-in shall be able to generate a CSV file that contains objects based on the data of multiple module instances and types
History
1.0.6 12.11.08 bk New plug-in
2.8 Import Plug-Ins (ImpPlugIn)
2.8.1 Introduction The purpose of this requirement is to use several plug-ins that imports module instance data from
one or multiple text formatted files. The format of the text files can differ in each concrete plug-in.
An import plug-in can cover one or multiple data formats like a list, a logical block, a document... that
has to be imported.
2.8.2 Associated Functional Requirements
2.8.2.1 Common
These requirements are valid for all import plug-ins.
ID Priority Description
10 3 The system shall provide the user the ability to select an automation system or a set of module instances that have to be used by an import plug-in.
History
1.0.3 27.10.08 bk 1st version
Automation Design Toolkit Functional Requirements Software Requirements Specification
Page 14
2.8.2.2 Import Plug-In for RSLogix5000
This plug-in has to be used to import module instance data from a CSV file that can be exported by
the RSLogix5000 software from Rockwell Software.
See appendix B.2 for more information's about RSLogix5000.
ID Priority Description
10 3 The plug-in shall be able to import a CSV file that includes controller tags which are based on multiple module instances and types.
History
1.0.3 27.10.08 bk 1st version
Automation Design Toolkit Non Functional Requirements Software Requirements Specification
Page 15
3 Non Functional Requirements
3.1 Quantity Structure The system has to handle the following quantity of components without stability or performance
issues:
Per Automation System:
Interface Signals 200
State Machines 10
Module Types 25
Module Instances 500
Import Plug-Ins 5
Export Plug-Ins 5
History
1.0.3 27.10.08 bk 1st version
3.2 Non Relevant Requirements The following non functional requirements are covered by the Software Design Platform; they are
not relevant for the present release:
- Accessibility
- Availability
- Configurability
- Data Integrity
- Maintainability
- Portability
- Traceability
3.3 Reliability The main requirements are covered by the Software Design Platform; the following requirements are
relevant for the features that will be implemented in the present release.
Requirements
ID Priority Description
10 1 The system shall detect invalid or missing user inputs and show an error message to the user with the cause of the error.
11 1 If the user cancels the process or the process will be terminated by an error, the system shall show the cause of the error in a message box and has to ensure that no data is modified.
History
1.0.3 27.10.08 bk 1st version
Automation Design Toolkit Non Functional Requirements Software Requirements Specification
Page 16
3.4 Adaptability The system shall be able to be extended with plug-ins. This requirement is covered by the functional
requirement PlugInHndl.
History
1.0.0 26.10.08 bk 1st version
3.5 Internationalisation The main requirements are covered by the Software Design Platform; the following requirements are
relevant for the features that will be implemented in the present release.
Requirements
ID Priority Description
10 1 All texts have to be written in English and implemented in a way that they can be translated if the entire system should be extended with additional languages.
History
1.0.0 26.10.08 bk 1st version
Automation Design Toolkit Description of the Software Design Platform Software Requirements Specification
Page 17
Appendix A - Description of the
Software Design Platform
This appendix includes the relevant description of the 1st release, called the Software Design Platform.
A.1 Overview The Software Design Platform is a client server architecture in which automation systems and their
contents can be handled by project teams in a distributed environment.
Other locationsOffice
System
Globalrepository
Project Team
Commissioning Peoples
A.2 Features The following main features are part of the Software Design Platform.
- Repository of automation projects that can be accessed locally on a client or global on a server.
- System wide log message handling and application configuration
- General support of team and offline work
- Integrated version management and change traceability
- System wide distributed data handling and storage in data bases
The 1st release is a running system including the data base and user interface.
A.3 System Interfaces The Software Design Platform provides specific interfaces and prepared components that have to be
used to implement the present release.
Descriptions of the components and how they have to be used can be found in [SDP-SDD].
The implemented component structures and their code documentation can be found in [SDP-API].
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 18
Appendix B - Standards and
Products
This appendix includes detailed information's about standards and other products that are used or referenced in this document
B.1 Standard: ANSI/ISA S88
B.1.1 Brief Description Abstract from http://en.wikipedia.org/wiki/ISA-88http://en.wikipedia.org/wiki/ISA-88:
S88, shorthand for ANSI/ISA-88, is a standard addressing batch process control. It is a design
philosophy for describing equipment, and procedures. It is not a standard for software; it is equally
applicable to manual processes.
S88 provides a consistent set of standards and terminology for batch control and defines the physical
model, procedures, and recipes. The standard sought to address the following problems: lack of a
universal model for batch control, difficulty in communicating user requirement, integration among
batch automation suppliers, difficulty in batch control configuration.
The standard defines a process model which consists of a process which consists of an ordered set of
process stages which consists of an ordered set of process operations which consists of an ordered
set of process actions.
The physical model begins with the enterprise which must contain a site which may contain areas
which may contain process cells which must contain a unit which may contain equipment modules
which may contain control modules. Some of these levels may be excluded, but not the Unit.
The procedural control model consists of procedures which consist of an ordered set of unit
procedures which consists of an ordered set of operations which consist of an ordered set of phases.
Some of these levels may be excluded.
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 19
B.1.2 S88 Physical Model The physical model can be used to describe the physical assets of an enterprise in terms of
enterprises, sites, areas, process cells, units, equipment modules, and control modules.
Enterprise
Site
Area
Process Cell
Unit
Equipment Module
Control Module
may contain
may contain
may contain
must contain
may contain
may contain may contain
may contain
Mainly used parts
Agitator
Tank
Line 1
Wet Part
Motor
The blue squares are examples of possible assets.
B.1.3 S88 Procedural Control Model The procedural control model shows the procedural elements that are combined in a hierarchical
manner to accomplish the task of a complete process as defined by the process model. The hierarchy
of identified and named procedural elements is illustrated in the following figure and consists of
procedures, unit procedures, operations, and phases.
Procedure
Unit Procedure
Operation
Phase
may contain
may contain
may contain
Filling
Production
Tank 10
Line 1
The blue squares are examples of possible assets.
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 20
B.1.4 Relationships The next figure shows how the two S88 models are related in usual projects.
Procedure
Unit Procedure
Operation
Phase
may contain
Area
Process Cell
Unit
Equipment Module
Control Module
may contain
may use
may use
may contain
may contain
may contain
may contain
must contain
may contain
may contain
Physical ModelProcedural Control Model
Agitator
Tank 10
Line 1
Wet Part
Motor
Filling
Production
Tank 10
Line 1
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 21
B.1.5 S88 State Transition Diagram of Procedural Elements The following figure shows a common used state transition diagram that follows the S88 rules:
Executing
Complete
Idle
Running
Restarting
HeldHolding
Aborting
Aborted
Hold
RestartingStart
ResetAbort
Interlocked
Interlock / Alarm
Alarm
Quiescent State
The grey ellipses indicate quiescent states. These states can include some assignment logic and are
mostly used to know if the element has reached a specific state.
Transient State
The blue ellipses (italic text) indicate transient states. These states include usually a sequential logic
that has to be executed when the state is active.
Transition
An arrow indicates a transition that can be initiated external (named arrows) or internal from the
procedural element itself (arrows without name).
Interlock
An interlock is combination of conditions to prevent the procedural element to start.
Alarm
An alarm is combination of conditions to prevent the procedural element to start and to bring a
running procedural element into a safe state (Held).
B.2 Product: Rockwell RSLogix5000
B.2.1 Brief Description Abstract of http://www.rockwellautomation.com/rockwellsoftware/design/rslogix5000/:
The RSLogix 5000 software is designed to work with the Rockwell Automation Logix platforms. With
RSLogix 5000 software, you need only one software package for discrete, process, batch, motion,
safety and drive-based applications.
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 22
The RSLogix 5000 software environment offers an IEC61131-3 compliant interface, symbolic
programming with structures and arrays, and a comprehensive instruction set that serves many
types of applications. It supports relay ladder, structured text, function block diagram, and sequential
function chart editors for you to develop application programs.
B.2.2 Project Data The entire data of an RSLogix 5000 project is stored in one file using a proprietary format.
B.2.3 Import/Export from/to L5K file The RSLogix 5000 software is able to save the entire project into a L5K file or it is able to open a L5K
file. The L5K file contains the entire data of a project by using a plain text format.
Documentation:
The file format is well documented in [RS5KMan]
Example of a L5K file:
PROGRAM Prg1 (Main := RoutineB, Description := "I $'am$'" "
$0034 a $"program$"")
TAG
st11 : DINT (RADIX := Decimal, ProduceCount := 0) := 2;
st12 : BOOL (RADIX := Binary, ProduceCount := 0) :=
2#00000000;
END_TAG
ROUTINE RoutineA
JSR(_2_LADDER, 0);
END_ROUTINE
ROUTINE RoutineB
RC: "$L ** ;MORE $";STUFF" do not include "more";
xic(st11) ote(st12);
END_ROUTINE
END_PROGRAM
The file contains a complete project with all its components. Each component has it's defined section
within the file.
B.2.4 Import/Export from/to CSV file
The RSLogix 5000 software is able to save all or a selection of Tags into a CSV file or it is able to open
a CSV file to add, change its Controller Tags dictionary.
Documentation
The file format is described in [RS5KMan-1].
Example of a CSV file:
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 23
The file contains a common header and contains one line per Tag or comment.
B.2.5 Import/Export from/to L5X file The RSLogix 5000 software is able to save parts of the program code into a L5X file (XML format) or it
is able to open a L5X file to import program code.
An example is not shown in this document, because it will not be used.
B.3 Product: Siemens STEP7
B.3.1 Brief Description Abstract from http://en.wikipedia.org/wiki/ISA-88 http://de.wikipedia.org/wiki/Step7:
STEP7 is the actual programming language of the Simatic S7 Programmable Language Controllers
family from Siemens.
STEP7 basically knows the main programming languages specified in the IEC61131-3 standard.
B.3.2 Project Data The entire data of an STEP7 project is stored in a data base. The data base structure is not public and
not documented.
B.3.3 Import/Export using STL sources The STEP7 software is able to save one or multiple data or functional blocks into a STL source file or it
is able to import in into the project.
Documentation
The file format is described in [S7Man].
Example of a STL source file:
FUNCTION_BLOCK FB6
TITLE = Simple traffic light switching
// Traffic light control of pedestrian crosswalk
// on main street
{S7_m_c := 'true'} //System attribute for blocks
AUTHOR : Siemens
FAMILY : Traffic light
NAME : Traffic light01
VERSION : 1.3
VAR_INPUT
starter : BOOL := FALSE; // Cross request from pedestrian
t_dur_y_car : TIMER; // Duration green for pedestrian
t_next_r_car : TIMER; // Duration between red phases for cars
t_dur_r_car : TIMER;
number {S7_server := 'alarm_archiv'; S7_a_type := 'alarm_8'} :DWORD;
// Number of cars
// number has system attributes for parameters
END_VAR
VAR_OUTPUT
g_car : BOOL := FALSE; // GREEN for cars_
END_VAR
VAR
condition : BOOL := FALSE; // Condition red for cars
END_VAR
BEGIN
NETWORK
TITLE = Condition red for main street traffic
// After a minimum duration has passed, the request for green at the
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 24
// pedestrian crosswalk forms the condition red
// for main street traffic.
A(;
A #starter; // Request for green at pedestrian crosswalk and
A #t_next_r_car; // time between red phases up
O #condition; // Or condition for red
);
AN #t_dur_y_car; // And currently no red light
= #condition; // Condition red
NETWORK
TITLE = Green light for main street traffic
AN #condition; // No condition red for main street traffic
= #g_car; // GREEN for main street traffic
The file can contain one or multiple complete functional blocks and /or data blocks.
B.4 Product: Wonderware Industrial Application
Server
B.4.1 Brief Description Abstract from: http://trainweb.wonderware.com/getstartias/ArchestrAArchitecture.htm:
Wonderware products enable conversion of plant data into plant intelligence. The Industrial
Application Server (IAS) is the core application development and supervisory control platform of a
Wonderware system.
The Industrial Application Server is built on Invensys' ArchestrA, the comprehensive plant automation
and information architecture that works behind the scenes of the latest Wonderware products.
The Industrial Application Server's underlying ArchestrA architecture facilitates the re-use of
engineering, standardization, peer-to-peer connectivity, remote diagnostics and administration,
source code control, and role-based data security.
Included in this overview of the Industrial Application Server is the Integrated Development
Environment (IDE). The IDE is used for configuration and connectivity to the IndustrialSQL Server real-
time historian and InTouch human-machine interface (HMI) software, allowing for real-time data
acquisition, alarm and event management, data manipulation services, and collaborative engineering
capabilities.
B.4.2 Project Data The entire data of an IAS project is stored in a data base. Wonderware recommends using the
Archestra IDE for data import and export instead of direct changes in the data base.
B.4.3 Import/Export Objects The Industrial Application Server software is able to save all or a selection of Objects into a CSV file or
it is able to open a CSV file to import.
Documentation
The file format is described in [IDE21Man].
Example of a CSV file:
; Created on: 14.03.2008 15:18:55 from Galaxy: <Plant>
Automation Design Toolkit Standards and Products Software Requirements Specification
Page 25
:TEMPLATE=$PIDELoop
:TagName,Area,SecurityGroup,Container,ContainedName,ShortDesc,ExecutionRe...
CON3_EVA_PIC6102,CON3_EVA_PSU1_Homogeniser,Default,,,EVA_PIC6102 Hydrauli...
CON3_EVA_PIC6122,CON3_EVA_PSU1_Homogeniser,Default,,,EVA_PIC6122 Hydraulc...
:TEMPLATE=$InputDevice
:TagName,Area,SecurityGroup,Container,ContainedName,ShortDesc,ExecutionRe...
CON3_EVA_FSH6127,CON3_EVA_PSU1_Homogeniser,Default,,,EVA_FSH6127 Homogeni...
CON3_HPP_FSH3181,CON3_HPP_PSU1_HPPSystem,Default,,,HPP_FSH3181 Lubricatio...
:TEMPLATE=$ProcessAlarm
:TagName,Area,SecurityGroup,Container,ContainedName,ShortDesc,ExecutionRe...
CON3_EVA12_QF401_PA_PumpAlarm,CON3_EVA_PSU2_PreConcTransfer,Default,,,Ala...
CON3_EVA21_QF401_PA_PumpAlarm,CON3_EVA_PSU1_Effect1,Default,,,Alarm on PU...
CON3_EVA22_QF401_PA_PumpAlarm,CON3_EVA_PSU2_Effect2,Default,,,Alarm on PU...
The file data is grouped by the object type and contains one line per object instance.
B.5 Product: Wonderware InTouch HMI
B.5.1 Brief Description Abstract from http://global.wonderware.com/EN/Pages/WonderwareInTouchHMI.aspx:
InTouch software provides graphic visualization which takes your operations management, control
and optimization to a whole new level.
B.5.2 Import/Export Tag Definitions The InTouch software is able to save all or a selection of Tag Definitions into a CSV file or it is able to
open a CSV file to import.
Documentation
The file format is described in [ITAppMan].
Example of a CSV file:
Automation Design Toolkit Glossary Software Requirements Specification
Page 26
Appendix C - Glossary
This glossary includes the system wide terms, abbreviations in alphabetical order. Some of the following items can be described more detailed in some of the pervious chapters. The glossary includes also some terms, abbreviations of the 1st release because of several similarities.
C.1 A ... E
ArchestrA
ArchestrA is a comprehensive plant automation and information architecture designed from the
outset to extend the life of legacy systems by leveraging the latest software technologies. See [Arch]
for more information's.
Archestra IDE
It's a user interface that represents the Integrated Development Environment of the Industrial
Application Server (IAS).
Asset
See appendix B.1.2.
Automation Framework
An automation framework is an Automation System including common used module types and
templates that will be used by the derived Automation Projects.
Automation Project
An automation project is an Automation System that represents a concrete project which can be
based on a commonly used Automation Framework.
Automation System
An automation system represents a real software system. An automation system can be either an
Automation Project or an Automation Framework. It contains a hierarchical structure of software
modules.
Client Host
A client host is a standalone application that can be used offline or online (connected to the server-
host). The client-host includes a Local Repository and its automation systems.
Controller Tags
It's the dictionary of Tags within an RSLogix 5000 project.
ControlLogix
It's the family of programmable logic controllers (PLC's) from Rockwell Automation.
Automation Design Toolkit Glossary Software Requirements Specification
Page 27
CSV
Abbreviation for Comma Separated Values or Character Separated Values, a text file format.
C.2 F ... I
Firebird
Firebird is a relational database management system offering many ANSI SQL 2003 features. It runs
on Linux, Windows, and a variety of UNIX platforms. Started as a fork of Borland's open source
release of InterBase, the Firebird codebase is maintained by the Firebird Project at SourceForge.
IAS
See Industrial Application Server (IAS).
IEC61131-3
The third part of the open international standard IEC 61131, and was first published in December
1993 by the IEC. The current (second) edition was published in 2003.
Part 3 of IEC 61131 deals with programming languages and defines two graphical and two textual PLC
programming language standards:
- Ladder diagram (LD), graphical
- Function block diagram (FBD), graphical
- Structured text (ST), textual
- Instruction list (IL), textual
- Sequential function chart (SFC), has elements to organize programs for sequential and parallel
control processing.
Industrial Application Server
A platform for distributed industrial applications from Wonderware, built on the ArchestrA system.
More details can be found in the appendix B.4.
InTouch HMI
A software product from Wonderware to visualize a process control system. More details can be
found in the appendix B.5.
C.3 J ... N
L5K
An L5K file contains the entire data of a ControlLogix project by using a plain text format.
L5X
An L5X file contains parts of the program logic of a ControlLogix project. It is based on a XML format.
Automation Design Toolkit Glossary Software Requirements Specification
Page 28
C.4 M ... S
PLC
Abbreviation for Programmable Logic Controller
Plug-In
A Plug In is a software component which extends the functionality of a software system dynamically
without code modification.
Rockwell Automation Logix Platform
See ControlLogix.
Root Module
The root module is the parent module type of all structural and functional modules. It is the only
module that cannot be removed from an automation system.
RSLogix 5000
RSLogix 5000 is the programming tool of the ControlLogix family of programmable logic controllers
from Rockwell Automation. More details can be found in the appendix B.2.
S7
S7 is the family of programmable logic controllers (PLC's) from Siemens.
S88 Physical Model
See appendix B.1.2.
S88 Procedural Control Model
See appendix B.1.3.
SDP
Abbreviation for System Design Platform
Server Host
The server host is the server of the system and runs normally on a windows server. The server-host
includes the Global Users List and the Global Repository including its automation systems. Client
hosts can connect to the server host in order to work online.
SourceForge
The world's largest development and download repository of Open Source code and applications.
Link: http://sourceforge.net/
STEP7
STEP7 is the programming tool of the S7 family of programmable logic controllers from Siemens.
More details can be found in the appendix B.3.
Automation Design Toolkit Glossary Software Requirements Specification
Page 29
STL
Abbreviation for Structured Text Language; it's a Siemens name of ST that is used in STEP7 (specified
in IEC 61131-3).
C.5 T ... Z
Tag
A tag represents an object within a PLC or HMI. It has a unique name, a data type and description.
Tag Definition
A tag definition is one data element of the InTouch HMI software. A tag definition can be an internal
data object or a data object that has to be read/write from another system like a PLC.
Automation Design Toolkit Literature Software Requirements Specification
Page 30
Appendix D - Literature
This appendix includes the referenced literature (websites and documents) in alphabetic order.
[Arch]
ArchestrA Website, http://www.archestra.biz/default.aspx
Invensys
[EA01]
Enterprise Architect, http://www.sparxsystems.com/products/ea.html
Sparx Systems
[CodeStyle]
Document Code Style Guideline for .NET Framework based Projects
Deleproject
[DevProc01]
Document Software Development Process
Deleproject
[FireBird]
Official Firebird Website: http://www.firebirdsql.org/ .NET Data Provider: http://www.firebirdsql.org/index.php?op=files&id=netprovider
[IAS01]
Wonderware Industrial Application Server, http://us.wonderware.com/products/appserver/,
Wonderware
[IDE21Man]
ArchestrA Integrated Development Environment (IDE) Users Guide, Last Revision: 8/23/05
Invensys Systems, Inc.
[ITAppMan]
InTouch HMI Application, Management and Extension Guide, Last Revision: 7/25/07
Invensys Systems, Inc.
[RS5KMan]
Logix5000 Controllers Import/Export Reference Manual, Publication 1756-RM084L-EN-P - January
2007 Rockwell Automation
[S7Man]
SIMATIC Programming with STEP7, Ref: 6ES7810-4CA08-8BW0, Edition 03/2006,
Siemens AG, Germany
Automation Design Toolkit Literature Software Requirements Specification
Page 31
[SDP-API]
Website containing the API documentation including UML figures of the Software Design Platform
Deleproject AG
[SDP-SDD]
Document Software Design Description of the Software Design Platform
Deleproject AG
[SDP-SRS]
Document Software Requirements Specification of the Software Design Platform
Deleproject AG
[SUB01]
Subversion, http://subversion.tigris.org/