Requirements Engineering Visualization Platform Architecture and Experiences Abhilash Gopalakrishnan Abhinna Chandra Biswal Ashoka Shyamaprasad Power Technologies Department India Development Centre, ABB Global Industries & Services Ltd. Bangalore-560048, Karnataka, India E-mail:
[email protected] Abstract— Systems Engineering organizations involved in engineering systems like automation in Power Systems are increasingly seeing time to market playing a major role in success. Considering the short turnaround time, the challenge is to improve product quality. Requirements engineering practices like scenario analyses could play a role in building better solutions. We have built an animation/simulation platform to support visual scenario building and subsequently playing which helps in Requirement Engineering. In this paper we discuss the architectural approach followed in the development of this software toolbox, sample scenarios and the feedback from practitioners. We also suggest the future steps in alignment with global standards. KeywordsIndustrial Automation; Agility; Systems Engineering; IEC 61850, OPC UA, Substation Automation, Power Generation Automation
I. INTRODUCTION The major constituents of Industrial automation systems in the context of power systems are Automation of Power Generation, Substation and Distribution. In the adverse business situations, time to market is getting more and more significant in today’s economy as in Fig. 1. The industrial automation systems are mission critical in nature.
Figure 1. Major Forces Driving Systems Engineering Today
A discussion of the objectives of these systems is essential, relating with the significance of the systems engineering and product quality. The primary equipment in the power plant are turbine, generator, motor, solenoid and pneumatic valves and pumps etc. The parameters that need to be monitored and controlled in the plants include pressure, temperature, flow and others. These parameters, otherwise termed process values are monitored using sensors and controlled with the help of actuators. Many of these parameters have unique thermodynamic and mechanical properties–for example, water flow doesn’t reach the set value immediately due to inertia and it takes time to reach that value. Therefore, in automation of power plant, the control systems are normally closed loop based on the reaction times, i.e. time taken from error detection till the correction made, the systems generally take fractions of seconds. These are based on Distributed Control System (DCS) concept. One more architectural aspect involves the amount of data or traffic in a distributed control system is on the higher side. In substations and utility automations, current and voltage represent the key parameters. These parameters are measured and monitored based on the current flows at CT and PT, and the systems is protected using circuit breakers and switchgears. In this case, the total reaction times are much lesser to be able to protect or isolate the faulty bays or feeders and could be in the ranges of few milliseconds. Isolation of the faulty element requires usage of open loop control. Being less distributed, these systems tend to have much high data rates [1]. If isolation of these elements doesn’t happen in a timely sequence, it could lead to blackouts as it happened for the northern grid in India in 2012. Instrumentation and Control (I&C) as automation systems are fondly called, turns out to be just 5% of the plant investments, but plays a crucial role in the protection and control of the investments. Industrial Automation System architectures have changed over time. Current trend indicates to focus on more open platforms and architectural separation between industrial automation information and communication protocols so as to enable efficient application of new generation communication in these systems [1] [2]. The present Requirements Engineering practices in industrial automation systems end up overseeing many important stakeholders. The prior paper had discussed the challenges in substation automation and proposed a
simulation platform for Requirements Engineering [3]. This simulation platform concept is architected, designed and implemented and some feedbacks from practitioners taken and incorporated. In this discussion we present our experiences building this platform–the features, the design challenges and architectural solutions applied and example scenarios considered.
Staff [4]. In the domain of industrial automation internal users could mean multiple stakeholders which include: a) System integrators, b) System Architects and Designers, c)
Control Logic Engineers,
d) Graphical Engineers, II.
REQUIREMENTS ENGINEERING PRACTISES IN INDUSTRIAL AUTOMATION SYSTEMS Most product organizations practice building database of Market Requirements, System Requirements and Product Requirements to bring more granularities at requirements. Requirements engineering involves developing requirements as well as requirements management. Developing requirements include elicitation, analysis, specification and validation. Requirements include varied levels of information such as: a) Business Requirements, User Requirements, b) System Requirements, Functional Requirements, c) Non Functional Requirement. As described in Figure 2. the stakeholders involved are at different levels and have varied objectives. In the area of business requirements we have business units who collect inputs from end users and customers. The inputs from customers or sponsors are often termed business requirements or market requirements. The inputs from real end users who use the systems often are termed user requirements. The product management within systems organizations is responsible for looking at the above inputs as a whole and defines System Requirements considering the internal users as well as the organizational objectives. System requirements could contain some quality attributes. Functional Requirements or Product Requirements are more detailed and specify the functional needs of each product. Non-functional requirements are based on architectural inputs and are essentially attached to scenarios. These requirements could include Business Rules, Quality attributes, External Interfaces and Constraints. The internal customers would include Marketing and Sales, Project Managers, Developers, Testers, Document Writers, Legal
Figure 2. Requirements - Levels and Key Roles involved
e)
Communication Engineers,
f)
Pre-FAT Testing Engineers,
g) Factory Acceptance Test (FAT) Testing Engineers, h) Site Acceptance Test Engineers, i)
Commissioning Engineers,
j) Communication Engineers. All these stakeholders have significant roles to play in the needs and design of these systems. The granularity or the level of detail expected by different stakeholders is different from the perspective of individual roles. We see this as the key success factor for the success of projects. The issues with requirements engineering still persisting, we see the emerging new challenges in systems engineering. This is none other than ‘Time to market’, the time from conceptualization to getting something that works well. Faster time to market gives a leadership position in the industry. Unlike consumer driven industries the automation markets are driven by long term vision and reliability concerns. But today the time to market in these systems as well have reduced significantly. Hence time spent on research, on envisioning new products as well as on development, testing and acceptance have to be significantly improved to maintain leadership positions. The message is clear, ‘Systems engineering has to be more flexible or agile’. Again in the systems engineering, unlike following agility in other disciplines requires an approach which can still contain feedback from multiple stakeholders. Architectural practises allow us to analyze the scenarios and obtain feedback to see if the architecture satisfies stakeholder needs [5]. Applying user scenarios to systems engineering and providing views to stakeholders, could hold key to the solution. We believe the answer lies in a long standing practice followed by defense and aerospace industries where simulation of scenarios is used for capturing requirements and feedback. The idea is to extend our senses making use of scientific visualization [6]. By bringing in narratives and visualization capabilities into a platform, we believe, we would be able to significantly enhance systems engineering going agile. We have followed the architectural approach of scenarios and implemented support for definition and animation or execution of these scenarios in a visual animated platform. We strongly believe that this would facilitate requirements clarity as well as shorter time to market in the lifecycles of the systems. In this paper we discuss the design challenges, modeling and software architecture aspects as well as feedback and inputs from industrial automation practitioners.
III.
THE SOLUTION APPROACH AND DESIGN C HALLENGES FACED IN PLATFORM DEVELOPMENT
A. Features As in Figure 3. the features of software based scenario visualization tool/platform includes creating scenarios, save scenarios, load and play scenarios. In order to interface with existing infrastructure, it needs to support interfaces to support 3rd party available using industry standards like IEC 61850. In product organizations the lifecycle of products could be of the ranges of 20 years. Hence the platform data has to interface also with lifecycle tools like version control. The platform also considers the fact that there are already existing simulation tools and models, which would be best to interface for the running of these scenarios on these models and getting a complete picture of analysis. In order to model metadata or the basic objects, the Base Object Model (BOM) from Simulation Interoperability Standards Organization is chosen to serve as the basis [7]. As in Figure 4. , Basic Object Model consists of two parts: (1) a model identification to define the type and identity of the element, (2) a conceptual model which defines the state machines and pattern interplays for the related entities. Interfaces is added as a third element for industrial automation systems architecture. Using Base Object Model, the industrial automation elements are modeled by approaching the following aspects as in Figure 5. B. Design Challenges 1) MetaData Modeling Model Identification could be used to identify the element. For example Model Identification could point to an IED or Controller type. Using the conceptual model the behavioral or runtime characteristics are defined. This is using state machine defintion for the element. To bring in an architectural angle and exploit the benefits of new generation communication, interfaces were defined for communication, memory and processor. Interfaces are an adaptation of the Base Object Model. The Model Mapping and Object Model Defintion are used in principle only. 2) Scenario Modeling using MSDL The user scenarios need to be described. The platform
Figure 3. Features of the Platform and External Factors
Figure 4. SISO Base Object Model Adapted for Industrial Automation
requires the ability to model scenarios and be able to save, load and play them. The Military Scenario Definition Language (MSDL) is adapted for this purpose. The adaptation is termed Scenario Definition Language. Scenario ID is reused from MSDL, and the Communication Sequence and Action Sequence are added to accommodate the industrial automation specific details. Scenario ID contains the Model Identification within. 3) Software Architecture Framework The software architetcure involves xml based defintions of Base Object Model (BOM). As in Figure 6. C++ programming language was chosen for the foundation architecture. The BOM parser loads these into the Base Object Model Class. The Qt Framework from Digia and Qt’s graphics view framework are used for building the visual or graphical representation and the animation framework [8]. The user is provided with a toolbox of BOM Objects–could be controllers, IEDs, operators, field equipment like circuit breakers, actators and so on. The user drag and drops the required objects from the toolbox and a BOM Object instance is created. When an instance of a BOM Object is created, the BOM Object instance appears as a QGraphicsItem wth viual elements and can be placed into the graphicsview. The user now interconnects the objects in the
Figure 5. Generic Controller Typed Modeled using BOM Adaptation
scenario. Using this approach a topology of the automation system is created. The user now goes ahead defining the dynamic or behavioral aspects which include the action sequence and communication sequence. These descriptions are then saved as a scenario and stored in format of Scenario Description Language . a) Base Object Model As in Figure 7. , the Base Object Model consists of Model Identification and its elements which include, Keyword(s), Point of Contact (POC)s, Use History for collecting historical information on feedback. Images of the object are incorporated as Glymph. Reference classes allow us to refer between different BOM types. b) Engineering Scenario Definition The Scenario Definition contains the ScenarioID which defines the environment, the forces and the details of the scenario including climatic conditions like atmospheric temperature, pressure and humidity etc. as shown in Figure 8. The communication sequence and action sequence are adaptation done for supporting industrial automation. Communication sequence is a collection of source and destination signals or interface points and the description of types of messages passed between them. The action sequence defines the processing action and control action performed by the particular instance of object on the scenario. To maintain reference to each BOM Object or type, Scenario ID contains a Model Identification which traces to the type of BOM defined. The Instance number of the BOM instance uniquely identifies the object on the scene. The action sequence could contain trip action or open or close circuit breaker or open valve to 25 degrees which are examples of actions taken in an automation scenario. This again involves storage in XML formats as defined by MSDL. c) Basic Communication Engine and Extensibility The Basic Communcation Engine consists of ability to add Sender and Receiver. The communication aspects are considered include MessageSize = 1522 Bytes as per IEEE 802.3 (Ethernet) Standard. Now Frame can be defined to suite any Application Protocol Data Unit (APDU) and Application
Figure 7. Base Object Model Class Model
Service Data Unit (ASDU) to be able to align with any type of communication. This allows us to be able to apply the principles of any of the application prototols and incorporate elements of layer two as well as application protocol stacks. Based on design considerations of Adaptive Communication Environment (ACE) the following design considerations are required for a communication engine [9]. a) Communication Dimension b) Concurrency Dimension c)
Service Dimension
d) Configuration Dimension The communication engine therefore is designed to incorporate a generic Socket API as base as shown in Figure 9. This is aligned to the aspects of communication dimension which would include:
Figure 8. Scenario Definition Language Figure 6. Software Architecture of the platform
IV.
CONCLUSION AND FUTURE WORK
The experiments point out the application in the areas of requirements engineering, innovation and communication explorations as well as demonstrations and training. The evolution of this platform plans to consider the key feedback which includes: A. ViewPoints for various Stakeholders An electrical engineer would need an electrical view based on single line diagram (SLD), where as a communication engineer would need a communication viewpoint. There could be few viewpoints which could be common across stakeholders like automation view.
Figure 9. Basic Communication Engine
a) Connection-less and Connection oriented, b) Synchronous and Asynchronous Messaging, c) Message Passing and Shared Memory. Staying at this abstraction would allow us to substitute the TCP/IP and Ethernet Stacks above there by letting us connect to existing infrasctucture of industrial automation which includes Ethernet, OPC UA and IEC 61850 all based on ethernet standards and mapping to ethernet communication [10]. The basic communication has an abstract layer with socket API which consists of principles for context management, connection management, data transfer, options and network addressing. The basic communication engine could be added to BOM Instances. 4) Demonstrator and Example Scenarios As in Figure 10. the platform is used to execute a few industrial automation scenarios and the results are encouraging. In an alarms and events scenario, the sensors obtain the field signals. Thes are then communicated to controller. The controller processing leads color changes in HMI which indicates alarm. These are used to demonstrate to practitioners and collect feedback.
Figure 10. Alarms and events scenario prepared using visualization platform
B. Analytical Capabilities and Reports The platform needs analytical capabilities to be able to do some basic time estimates and calculations which could benefit in architecture and improvements of automation systems. The results of these could be generated as reports to demonstrate the benefits various industrial automation elements. ACKNOWLEDGMENT We take this opportunity to thank Power Technologies R&D at ABB India Development Center, ABB Global Industries and Services Ltd, for the kind support in this work. REFERENCES [1] [2] [3]
IEC61850 Standards – Part 1 to 10 Open Connectivity – OPC UA Standards Part 1-13 Ashoka Shyamaprasad, Abhilash G. and Abhinna Biswal, “Requirements Engineering in Substation Automation using Simulation Platform” , Recent Advances in Communication, Control and Computing Technology, IEEE Student Branch, Sarvajanik College of Engineering and Technology, Surat, India. [4] Karl E. Wiegners, “Software Requirments- Practical Technigues for gathering and managing requirements throughout the product development cycle”, Second Edition, Microsoft Press ISBN 8107853071-6, 2005 [5] Rick Kazman,Gregory Abowd,Len Bass and Paul Clements "Scenario Based Analys of Software Architecture” , IEEE Software, Nov 1996. [6] Kwan-Liu Ma and Isaac Liao, Jennifer Frazier, Helwig Hauser, HelenNicole Kostis “Scientific Storytelling Using Visualization”, IEEE Computer Graphics And Applications, January/February 2012. [7] Simulation Interoperability Standards -SISO-STD-003-2006 and SISOSTD-008-2010 [8] Qt Graphics View and Qt Animation Framework http://qt-project.org/doc/qt-4.8/graphicsview.html [9] Douglas C Schmidt, Stephen D Hosuton, “C++ Network ProgrammingMastering Complexity with ACE & Patterns“, Addison-Wesley Longman - 2002, ISBN 0-201-60464-7 [10] IEEE Standards – IEEE 802.3:Ethernet
