pontus karlsson - semantic scholar · 2015-07-29 · flow, temperature and tap changer positions....

Distribution Management Systems

Pontus Karlsson

Master ThesisStockholm, Sweden 2007

XR-EE-ICS 2007:006

An Evaluation of Functionality and Modifiability

Abstract. This report describes how a functionality and modifiability study at ABB Network Management was carried out. The study aim was to evaluate how well the functionality of ABB’s control system fits the business processes of E.ON. This study was also investigating what level of modifiability ABB’s control system provides.

A meta model which was based on modifiability theory has been developed. The entities in the meta model have attributes that have positive or negative impact on system modifiability. The modifiability analysis was conducted by modelling ABB’s DMS according to the meta model and applying a specific change scenario. The workflow of the functional evaluation was as follows: E.ON’s business processes were translated into requirements in order to analyse into what extent the requirements were fulfilled by the system.

The study revealed some gaps between the outage management process and ABB’s DMS. Suggestions of improvements were discussed in order to make the DMS system more competitive. The modifiability study revealed that the system could adapt to the change scenario rather easily.

Keywords. DMS, business process, meta model, outage management

Acknowledgements

I would like to express my gratitude to the following persons who have contributed to this work.

• Per Närman (KTH), my supervisor during this project who has contributed with many valuable comments.

• Elin Hammar, who has letting me use her work in my thesis.

• Kjell Gustafsson (ABB) and Per Clasén (E.ON), who have initiated this project.

• Samir Lodhi, Staffan Norén and Carl-Gustaf Lundqvist (ABB) who, during my time at ABB, have answered many questions.

• Robert Lagerström (KTH), who has been involved in the modifiability study and Mathias Ekstedt (KTH), who was helpful during the start up of this project.

• Göran Svensson and Roger Nilsson (E.ON) who have contributed with interesting site visits.

I also would like to thank everyone else at ABB/E.ON who has been helpful in various ways.

Tank you all!

Pontus Karlsson

Table of Contents

Abstract. 2 Keywords. 2 Acknowledgements 3 Table of Contents 4 1 Introduction 4

1.1 The Electrical Power Process 4 1.2 Electrical Power System 4 1.3 Outage Management 7 1.4 Study Background 8 1.5 Objectives 8 1.6 Questions at Issue 9 1.7 Delimitations 9

2 Method 10 2.1 Functional Evaluation 10 2.2 Modifiability 12

3 Business Processes and Information Technology 14 3.1 Business Processes 14 3.2 Managing Information Technology/System 15 3.3 Change Management 15

4 Requirements engineering 17 4.1 The Requirements Engineering Process 17 4.2 The Use of Requirements Engineering in This Study 17 4.3 Analysis of functional fit 18

5 Modifiability 19 5.1 Software Architecture 22 5.2 Software Architecture Tactics which Affects Modifiability 22 5.3 Software Components Dependencies 23 5.4 Aspects of System Changes 24 5.5 Meta Model 25 5.6 Method of Analysis 27

6 Case Study Method 29 6.1 Sources of Evidence 29 6.2 Data Collection Functional Evaluation 30 6.3 Data Collection Modifiability Study 31

7 Collected Data 32 7.1 The Outage Management Process 32 7.2 Network Manager 32 7.3 Other E.ON Systems 33

7.4 DMS Functions 33 7.5 Identified Problems 33 7.6 Modifiability 33

8 Analysis and Discussion 36 8.1 The Outage Management Process – A Suggestion for the Future 36

9 Conclusion and Further Studies 38 9.1 Conclusion 38 9.2 Further studies 38

10 Method discussion 39 REFERENCES 40

Appendixes (not available in the public version of this report)

Appendix 1 – Description of DMS Functions Appendix 2 – DMS Functions Appendix 3 – Activity Descriptions Appendix 4 – Requirements Appendix 5 – Identified problems Appendix 6 – Discussion Appendix 7 – Modifiability Study

4

1 Introduction

This report is the result of a Master thesis written in collaboration with Dept. of Industrial Information and Control Systems, Royal Institute of Technology (KTH) and the power control system vendor ABB Network Management. The beginning of this chapter will introduce the reader to the electric power process and power control systems, which is followed by a section describing why this study was carried out. The reader who is familiar with power control systems can skip the next two sections.

1.1 The Electrical Power Process

Cegrell and Sandberg [1] divide the electric power process into four steps, which include generation, transmission, distribution and consumption (Figure 1). A nuclear or a water power plant can for instance accomplish generation of electric power. An important factor regarding generation is that electric power must be consumed at the time of production, which the power control system must be able to handle. Transportation of electrical energy between different geographical areas is called transmission. The actual transmission voltage is about 130-400 kV, the high voltage is motivated because of its minimization impact on transmission loss. Distribution on the other hand operates on lower voltages around 10-40 kV and is the part in the power process that provides the customer with electrical energy. The final step in the power process is consumption where the consumer, with very few limitations regarding load or time for consumption, consumes electrical energy. To meet this demand is of course an important task for the power system.

Figure 1 – The power process

1.2 Electrical Power System

Kundur [2] describes an electric power system as a system, which converts non-electrical energy into electrical energy and transports it to its consumption point. A power system should according to Kundur [2] fulfil the requirements below.

• Manage changing load for active or reactive power.

• Provide energy at minimum cost, but also safeguard the environment.

• The system output must meet minimum standards regarding reliability and constancy of voltage and frequency.

The main objective regarding power operation is to keep the system in a normal mode. Kundor [2] is proposing a model where other possible modes are alert, emergency, in extremis and restorative. The alert mode is entered if the values of critical variables differ too much, from what is considered normal. The values are still at this point within their acceptable limits but the system is ready to enter the emergency sate in case of emergency. An emergency occurs for instance when voltages are too

Generation

Transmission Distribution Consumption

Dept. of Industrial Information and Control Systems

KTH, Royal Institute of Technology, Stockholm, Sweden

5

low. If the system is close to failure, then the in extremis mode is entered. The restorative mode is responsible for system restoration after the in extremis mode have been entered. Cegrell [3]suggest a similar model where the in extremis mode is left out which implies that the emergency mode is the only state handling emergencies.

Supervisory Control and Data Acquisition The power control systems of today are based on SCADA (supervision control and data acquisition) systems. SCADA systems have been used in the power industry since the late sixties [4]. To be able to understand the structure of a control system one must distinguish between different control centres. There are national, regional, district and station control centres. A national control centre operates on the national level and is in charge of a specific country’s power system. Every national control centre is interconnected with several region control centres, one step down in the control centre hierarchy (a region is a subset of a specific country’s geographical area). Further down in hierarchy are the district control centres, which are responsible for controlling a city or perhaps a big industry. A station control centre could manage a power plant, a transformer substation a switchyard or similar. [3] Since a SCADA system is a distributed and hierarchical system it collects data from power plants and substations which are sent to the central system [3]. The data is sent to the control centre by the remote transmission units (RTU). The RTUs, which are spread out over the power network are sending data about every 2 seconds [4]. It is also possible for the operator to enter data manually or to use calculated data [3]. Examples of typical measured values, which are collected from substations, are: voltage, active and reactive power flow, temperature and tap changer positions. The system often checks these values to determine if they are within their normal boundaries, this is called limit value monitoring [3]. The system status indicator helps monitoring alarm signals, circuit breakers and disconnectors [3]. These signals are collected from the whole power network. If a value differs from its previous value, stored in the database, the system will react. A SCADA system could also provide trend monitoring where the monitored value is displayed in relation to its variation over time. This is a useful tool when the operator is searching for possible errors. All real time data are stored in the system database, before doing so the system classifies the data, stores which substation the data belong to and put a time stamp on it. [3] According to Cegrell [3] a SCADA system has the following control functions: individual device control, control messages and both sequential and automatic control schemes. Individual device control is a set of commands, which provides elementary functions for controlling the power system. Starting a generator or to set a circuit breaker are examples of such functions. The control message function is used to transmit control messages, which are used for regulating equipment that needs supervision. A sequential control schemes is a set of control functions, which can be executed in a predefined order. If sequential control function triggers automatically it is called an automatic control function, such functions are executed at a certain time or event.



6

Distribution Management System There exist several definitions of what functions that should be included in a Distribution Management System (DMS). This thesis will use the view point of Cassel [5] who defines a DMS as: ”…a computer control centre for distribution control that contains traditional SCADA functions that analyze present and future conditions on the distribution system to support distributions operations”. As mentioned in the definition a DMS has SCADA functions as data acquisition, historical data storage and support for analysing and presenting data for the operator. It is also possible to integrate a DMS system with other systems. Cassel [5] suggests a model consisting of five layers that describes the architecture of a DMS system. SCADA functions such as data acquisition and control are placed in the first layer. In the second layer are the substation automation functions; these functions are for controlling a substation with the stations own acquisitioned data. The next layer is the feeder automation functions that are functions for controlling feeders. Functions for analysing the power flow are central for DMS system and are placed in the fourth layer. The final layer is the interfaces to other systems. A brief explanation of some of these systems will follow in the next section.

Energy Management System An Energy management system (EMS) is an important part in a power control system. An EMS controls transmission and generation in the same way as a DMS handles distribution [6]. Many DMS functions can also be found in an EMS, but the two systems differ in some aspects. A DMS receives information from a larger amount of RTUs and consequently require a larger database for storing information. An EMS has a higher number of remote controlled devices compared to a DMS [5].

Geographical Information System A geographical information system (GIS) could be used for presenting and generating maps [28]. The idea behind integration between a GIS and a DMS is to provide the DMS with a graphical interface where the power network can be visualized in real-time [7]. Other benefits are data sharing and a graphical interface for remote control which speeds up operations performed on switches [7].

Customer Information System The role of the Customer Information System (CIS) is to handle customer data such as addresses and subscription status. The CIS can for instance be used for call centre staff to store information about local blackouts that have been reported by different customers. By CIS/DMS integration valuable information about system failures could be passed to the control centre operator. [5]

Enterprise Resource Planning An Enterprise Resource Planning (ERP) system is a system for managing all kinds of company information. A CIS could be included in an ERP system but also many other types of modules could be included, logistic and accounting are two examples of such modules. It is also possible to integrate an ERP system with a DMS, which enables information sharing between the two systems. [8]

Load Management System A load management system controls peak demand and could provide Automatic Meter Reading (AMR) [9]. Other possible functions are remote meter testing, tamper detection and customer outage detection to name a few [5].



7

1.3 Outage Management

This report will focus on the outage management process and a description of the process is therefore in order. In the figure below is a general outage management process described. More detailed processes are described in [31].

Figure 2 – A general outage management process

Outage Indication The first step in the process is the outage indication where a fault is reported. This could be done by trouble reports from customers or SCADA detection. Important outputs from this sub process are the outage location and fault type. If possible, the DMS operator minimises the fault area by performing SCADA remote switching operations.

Dispatching Crew The DMS operator needs to contact a suitable field crew in order to get the outage restored. If such DMS functionality is not available, then phone communication is used.

Outage Restoration The physical part of the outage restoration is performed by the field crew which removes trees from power lines, replace fuses or similar. Before such activities can take place the crew working area must be de-energised, which is accomplished by remote or manual switching. When the work of the crew is done the power is switched back on and the outage is restored.

Outage Status Notification The outage status notification is an ongoing activity during the outage management. The purpose of the outage notification is to inform customers about the outage status and estimated time of restoration (ETR).



8

1.4 Study Background

ABB Network management is a company in the ABB Power Systems division. One of their main products is power control systems developed for controlling different aspects of the power process. Network Manager is the name of a SCADA/EMS/DMS system developed by ABB Network Management. This system handles both the transmission and the distribution parts of the power process. It is important for a company like ABB Network Management to constantly evaluate their product in order to get information about how well their products fit their customers need. This information can lead the way to product improvements, which in turn can lead to competitive advantages. Shapiro and Varian [24] discuss the importance of “knowing your customer”. But what do the customers really need? In this report that question will be answered by a study of the customers business process, followed by an evaluation investigating in what amount the control system functions are supporting the business processes. However to map these business process falls beyond the scope of this thesis, fortunately a study like that has been performed in another master thesis [31]. That thesis is based on the processes of the electric power company E.ON Elnät Sverige AB, which is a user of ABB Network Management’s control system. In this thesis, a functional evaluation of ABB’s DMS was performed, which was based on the processes available from E.ON. The evaluation was accomplished by comparing system functions to E.ON’s business processes. But what happens if the processes change over time? Can the system adapt to such modifications? A high level of system modifiability is consequently something to strive for. Different customers also need different solutions regarding system integration, which is another fact that motivates the need for a high level of modifiability. Another issue, which also indicates the importance of the subject modifiability, is that the cost for software maintenance could be more than 90 percent of the money spent during the software life cycle [25]. Therefore this study will also cover aspects of modifiability.

1.5 Objectives

The aim of this study was to evaluate how well the functionality of ABB’s control system fits the business processes of E.ON. This study has also investigated what level of modifiability ABB’s control system provides, in relation to a specific change scenario.



9

1.6 Questions at Issue

• How is ABB’s power control system operating?

• How well is the functionality in ABB’s power control system supporting the business processes of E.ON?

• How easy can ABB’s power control system be adapted to changes in E.ON’s processes?

1.7 Delimitations

The processes that were available from the E.ON master thesis, which were covering outage management processes, delimitated the functional evaluation. Both a planned and an unplanned outage were considered. The functional survey was only covering three different ABB sub systems although E.ON has several other ABB systems installed. The studied systems were selected by ABB and were most relevant for the outage management process (see chapter 7.2). A change scenario, i.e. a fictive but still possible modification of E.ON’s process which implies system modification, was studied in order to determine how well ABB’s DMS could be adapted to changes in a specific case. Only architectural aspects of modifiability and not code level implementations were considered due to limited time resources.



10

2 Method

This chapter describes how this study was carried out, meaning that the methods for the theoretical as well as the empirical parts of the report are described. As mentioned in the introduction, this study is divided into two sections, which addresses functionality and modifiability respectively.

2.1 Functional Evaluation

In figure 3 is the workflow of the functional evaluation described. Every step of the workflow is further discussed in the following chapters.

Figure 3 – Functional evaluation

IT/business Alignment Theory The IT/business alignment section of the report was built up using articles and books. The articles were collected from Google Scholar and IEEE Explore. Key words were: business process, system functionality, IT and change management. The aim of this chapter was to answer the question how the use of information technology (IT) can be evaluated in relation to a company’s business needs. The theory, which this chapter provided, inspired the method for the survey of functionality.

Empirical Data ABB The data collection was performed as a case study during November – January 2006/2007. In this study three types of sources namely documentation, interviews and physical artefacts were used. The collected documentation was system descriptions regarding functionality and architectural aspects



11

Empirical Data E.ON Elnät AB The empirical data collection from E.ON was performed by Elin Hammar [31] and resulted in process descriptions regarding outage management. These processes descriptions were clarified in activity descriptions, which later on were translated into requirements (chapter 4). In addition to this study, interviews have been held at a control centre in Norrköping where operators were asked about which DMS functions they are using in their daily work. They were also asked if they saw any problems with the current way of working.

Survey of Functionality The purpose the functional survey was to get a picture of the current situation regarding the DMS functionality that is installed at E.ON. In addition, all DMS functionality that ABB’s DMS could provide was also included in the functionality survey. The output from this process was the functional descriptions available in Appendix 1. The functions were also modeled as hierarchies (Appendix 2) in order to improve the readability [29].

Requirements Engineering Theory The requirement engineering section served as a background for the use of requirements engineering in the analysis (chapter 4). The requirement engineering process, which is described, is based on the work of Ian Somerville.

Analysis of functional fit and Suggestion of Improvements How these two processes were conducted can be read in chapter 4.3. The key issue was to use requirements engineering in order to identify functional gaps, which in turn could inspire the process of making suggestions of system improvements.



12

2.2 Modifiability

Figure 4 displays the workflow of the modifiability evaluation. Every step of the workflow is further discussed in the sections below.

Figure 4 – Modifiability evaluation

Modifiability Theory The theory chapter which addresses the topic of modifiability was built up by using Extended Influence Diagrams (EID), which is a method developed by Johnson et al. [18]. The method is a tool for developing a theoretical framework for architectural analysis with a high level of traceability and includes, in short terms, the following steps. Sentences which addressing the variable under consideration, in this case modifiability, are collected from different articles and kept as evidence. These sentences are later on analysed in order to determine in which way a specific sentence clarifies aspects of modifiability. The EID process, which includes building up a model using an intermediary notation where classes, variables, values and their relations are defined, is applied on to these sentences. The model built up by the intermediary relation is later on merged and cleaned up i.e. similar variables is merged into one and multiple instances of classes are removed. Finally the intermediary notations are translated into an EID. [18] The purpose of the use of the EID method in this study was not to develop a bullet-proof EID, which reflects every single aspect of modifiability. The use of the EID method was motivated because of its potential of creating a meta model for modifiability based on theory. Relevant articles covering modifiability were collected from Google Scholar and IEEE Explore, key words were: software architecture, modifiability and flexibility. The collected articles were scientific papers in order to improve the quality of the study.

Creation of Meta Model A meta model can be defined as “a precise definition of the constructs and rules needed for creating semantic models” [27]. In other words, a meta model defines all entities and relations that are needed to build a model of the studied subject. Another clarification is that the meta model only is designed for describing a special part of the world in order to be able to make a model for a specific purpose [27]. The original EID was limited to the EID presented in chapter 5. Decisions on what to keep and what to reject was based on how easy the different variables were to measure. The selection was also



13

Data flow

Computational Component

based on the study delimitations, meaning for example that the study of code level implementation was rejected. Another aspect of the selection process was to avoid having two variables in the final EID that were too similar. When the selection was made the meta model was created by using the variables in the final EID as elements in the meta model. This is illustrated in an example below. Example of an EID to meta model translation:

Article text like: ”A system’s software structure reveals how it is constructed from smaller connected pieces. The structure is described in terms of the following parts: 1. A collection of components /…/ 2. A representation of the connections between the component….” [17] gave the following EID (figure 5).

Figure 5 – EID example This EID was then translated into the meta model entities “Connections” and “Components”. The figure below shows an example on how these entities were represented.

Figure 6 – Meta model example

Empirical data ABB The empirical data was based on interviews aiming to identify the correct values of the attributes in the meta model. The interviews were also input to the modelling of the architecture. The method for the data collection is explained further in the case study method chapter.

Modelling The model was visualised by using the software tool Microsoft Visio. The model was based on empirical data from ABB, which were representing elements given by the meta model.

Analysis The method of analysis can be read in chapter 5.6. The method was based on grading scale in order to put weaknesses and strengths of the system modifiability into focus.



14

3 Business Processes and Information Technology

Information technology is more and more used in today’s business and is consequently something which affects companies to a larger extent. This chapter will focus on the alignment of IT and business in order to provide the theory necessary for the functional evaluation.

3.1 Business Processes

Dayal et al. [19] defines a business process as: “a persistent unit of work started by a business event such as an invoice, request for proposal or a request for funds transfer.” The definition is followed by a description of a process as a unit built up by sub processes and tasks, which are triggered by business rules. These tasks and sub process are related to recourses, which are organisational units. All these elements and their interaction are a part of the process description [19]. Another definition of a process is provided by Davenport [20]: “a structured, measured set of set of activities designed to procedure a specified output for a particular customer or market.” Davenport also states that it is important for a process to have a well defined in- and output. The outage management process, described in the introduction, is an example of a process where a black out triggers the process to execute. Output from the process is power restoration. Mårtensson and Stenskog [33] have studied what distinguish a good business process and their work is summarized in the figure below. Customer satisfaction, productivity, quality, and lead-time are characteristics, which are indicating the value of the process output. The flexibility and the short-term management (process control) of the process are affected by these characteristics. Process enablers like process design, human actors and information technology (IT) are also affecting the process output, which in turn is affected by the business strategy and the long term management (process management).

Figure 7 - Process characteristics and enablers [33]



15

3.2 Managing Information Technology/System

According to Bergvall and Welander [30] there exists two ways of evaluating an information system. One approach is to use metrics and the other is to use a subjective method where the system stakeholders are asked for their opinions. Studies have shown that it is difficult to gain profit from system evaluations; one way to increase the profit is to use the result as input for setting new system goals. [30] Axelsson and Goldkuhl [34] state that an information system and its architecture should meet the requirements to the following system attributes:

• Functionality

• Modifiability

• Understandability

• Integration to other systems

• Support different areas of responsibility across the organisation.

• Technology utilization An information system should provide relevant functionality and have a high level of modifiability in order to adapt to future changes. All systems must be understandable by the system stakeholders. System architecture, system boundaries and its interaction to other system must be understandable which includes proper documentation. [34] Another important issue is the integration with other systems, in order to avoid redundant data and unnecessary data processing. An information system and its architecture should also provide clear system boundaries, which enable staff members to have different areas of responsibility, for example financial or system development. Technology utilization is about achieving cost-effective usage of information technology and the infrastructure available. [34]

3.3 Change Management

Goldkuhl [35] describes a model for change management relevant for information systems. The first step is the problem analysis where problems are being identified as well as the causes and the problem effects. The next step is goal analysis where new goals are identified by considering existing goals. These goals are reviewed if necessary. Business Analysis is the next step of the change management process and is conducted in order to understand the business. A list of needed changes is later on created which are based on the problem, goal and business analysis. The last step in the process is to come up with relevant changes. One central issue when it comes to process management is to understand the present situation in order to manage changes leading to an improved situation. Creating a model of the present situation as well as the possible improved situation can be a tool for understanding and managing changes to business processes. [32] When discussing change management a central issue is what should be changed: adapt the process to a new IT solution or developing IT that supports the current process. Davenport states that companies, which change the process, are more successful [38].



16

Legacy systems are often an existing part of a company’s information technology. When discussing replacement or modifications of such systems a good start is to consider the present situation and asking questions about the future. Here are some examples of such questions: What are the drawbacks by using the legacy systems in the future? Is the situation growing worse over time? Can the system keep up with customer demand and expectations? Is the system competitive? A discussion about alternatives should also be added to the present and the future situation. [37] Lucas [36] points out the importance of involving the senior management in IT decisions. Every company should also involve IT in its corporate strategy and have a vision for the use of IT in the organisation.



17

4 Requirements engineering

How can a business process be compared to system functionality in order to evaluate in what extent the functionality supports the business processes? The aim of this chapter is to answer that question by using requirements engineering.

4.1 The Requirements Engineering Process

Figure 8 below is showing the requirements engineering process according to Sommerville [21]. The process starts with a feasibility study where business requirements and a sketch of the planned system is analysed. The analysis is resulting in a feasibility report answering the question if it is reasonable to proceed with the requirement process and the system development.

Figure 8 – The requirement engineering process [21] In the next two steps of the process the system functionality and constraints are discovered, classified, prioritised, and specified by the requirement engineer and the system stakeholders. The output from these steps is a system model and user and system requirements. The final step in this process is the requirement validation. Reviews, prototyping and test-case generation can according to Sommerville [21] be methods for requirements validation. System developers and stakeholders could perform reviews at formal or informal meetings where the requirements are discussed. Prototyping involves demonstration of a prototype for the system customers in order to validate the system requirements. The idea behind a test case generation is to validate the requirements with the help of tests cases. If a test case is impossible to develop it indicates that something is wrong with the requirement.

4.2 The Use of Requirements Engineering in This Study

Is it possible to map business processes to system functionality by using requirements? In a study made by Rolland and Prakash [22] has ERP requirements been mapped to customer requirements in order to provide a functional fit between an off the shelf ERP system and a company’s business processes. A similar approach was made in this thesis where processes descriptions were translated into requirements in order to apply a requirement validation to see if the processes and the system functionality fit.



18

4.3 Analysis of functional fit

The activity descriptions (Appendix 3) and the functional descriptions (Appendix 1-2) were compared one by one in order to analyse the functional fit. A distinction was made between a purchased function and a non-purchased function since DMS functionality can vary among customer installations. Consequently two questions were arising (questions 1-2 below) which were answered during the analysis. The mapping between activities and functions were inspired by requirements engineering where activity steps were seen as requirements in order to validate if the ABB system functions partly or fully could fulfil the requirements (chapter 4.1).

1. Is/are there any purchased function/functions, which fully supports the activity step? 2. Is/are there any purchased function/functions, which partly supports the activity step?

The use of this method is illustrated in a straightforward example below.

Activity description: When an outage has been verified a normal action for the DMS operator often is to contact a field crew in order to get the outage restored. Requirement: The operator shall be able to inform a suitable field crew about the outage location, probably outage cause, comments etc. Comment: “Suitable” is defined as right geographical area and status Example of a functional fit: In their DMS the electric power company has an “assign crew function”, which is integrated with the field crew’s information system. The function ”list crew” provides the operator with a list of suitable crews and the assign crew function enables the operator to send an electronic message to the crew’s information system with most of the message information predefined. Example of a partly functional fit: The electric power company has an ”assign crew function”, which is not integrated with the crew’s information system. The operator uses the “list crew function” to find a suitable crew and their phone number in order to contact the crew by phone Example of a functional gap: Previous mentioned functions are not installed and the operator has contact information to all crews on a piece of paper or similar. The operator uses the phone to contact a crew that the operator finds appropriate. When questions 1-2 have been answered (for every activity), a view of the present situation is appearing. The requirement validation reveals functional gaps and identifies key functions, which fulfil the requirements. Since the purpose of a system evaluation often is to come up with improvements the result of the above analysis could serve as an input to a change management process. A change management process often starts with a presentation of the current situation in order to analyse relevant change suggestions (chapter 3).



19

5 Modifiability

Software system modifiability can be defined as: “The ease with which a system can be adapted to changes in the functional specification, in the environment, or in the requirement” [13]. This chapter’s focus is on the architectural aspects of modifiability meaning that code level implementations are not under consideration. In the figures below the EID of modifiability is presented. The EID was developed as described in the method chapter in order to extract quantifiable attributes from the concept of modifiability. In the following sub chapters the figure will be described, where you also can read how the figure relates to the meta model.

Figure 9 – EID Overview



20

Figure 10 – EID Software Architecture

Figure 11 – EID Software Architecture Tactics

Software System Passive Data Repository

[Instance of] Software Architecture

[Instance of] Quality Goals

Software System Design

Software System Structure

Software System Connections Between

Components

Software System Active Data Reposiory

[Instace of] Software System Designer

Software System Functions

Software System Function Allocation

Software System Components

Software system Computational

Component

Software System Process

Software System Uni-/Bi-directional

Control FlowSoftware System Uni-/Bi-

directionalData Flow

[Instace of] Software System Requirements



21

Functional dependencies

Quality-of-service

Syntax

Semanticis

Exictence of Component Dependencies

Data Flow

Figure 12 – EID Component Dependencies

Figure 13 – EID System Change

[instance o]f System Change

Number of Comonents to

Change

Component OwnerComponent Size

Number Lines of Code

Local

Non-Local Architectural

Number of Component Versions



22

5.1 Software Architecture

According to Lasing et al. [14] the IEEE Standard 1471 defines software architecture as follows: “Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution.” The software architecture affects the modifiability of a system [12],[16]. A presentation of some factors, which have impact on the software architecture and indirectly affects the system modifiability, is available below.

Software System Design Kazman et al. [17] suggest a structure for the software architecture containing components and connectors. Components could be processes, computational components (e.g. a procedure), passive data repositories (e.g. a file) and active data repositories (e.g. an active data base). Connectors on the other hand are represented by uni-/bi-directional control and data flows. Kazman et al. [17] also states that functions and their allocation over components is a part of the description over a system’s software architecture which gives the following entities to the meta model: system, components (of various kinds), connectors, and functions.

Software System Requirements When a system designer allocates functions over the system architecture the designer must consider system requirements, which can have impact on modifiability [16],[17]. The system requirements will therefore be an attribute in the meta model describing the system entity. Please note that only requirements that affect modifiability will be considered. Such requirements are typically requirements that promote or prevent modifiability. A security requirement could for instance be demand for replicated databases, which is something negative for modifiability.

Quality Goals Business goals could be incorporated in the system quality goals and affect modifiability [11]. Therefore quality goals, which can have positive or negative effect on modifiability, will be included in the meta model as an attribute on the system level.

5.2 Software Architecture Tactics which Affects Modifiability

Since this report deals with modifiability on the software architecture level it is appropriate to discuss some software architecture tactics, which affect the modifiability in a software system.

Number of Communication Paths The modifiability of a system is affected by the amount of incoming and outgoing communication paths for each component under modification. To reduce the number of communication paths is a tactic for increasing the modifiability [11]. Therefore will the number of communication paths be an attribute in the meta model that is describing each component.

Level of Compression The level of separation and compression of components effects system modifiability where separation promotes modifiability and compression has negative impact on modifiability [10]. The level of



23

separation is in this report measured by the number components with well-defined interfaces, which is included in the meta model as an attribute.

Level of Abstraction Use of virtual machines promotes modifiability and is a mechanism for abstraction [10], [11]. A virtual machine is defined as “a component whose function is to hide its underlying implementation” [10]. In the meta model, the number of virtual machines will be an attribute on the system level.

Level of Replication Replication, which implies existence of component duplication, has a negative impact on modifiability since a modification has to be implemented in two components [10]. Replication, which is included in the meta model, is in this report measured as the number of duplicated components.

Level of Resource Sharing Shared resources reduce the component coupling and therefore increase the modifiability. A change in a shared resource implies that the change can be made in one component instead of several. A resource, in this case, could be either a service or data [10]. To be able to measure this, the number of shared resources will be an attribute in the meta model.

5.3 Software Components Dependencies

Dependencies to other architectural element obstruct the modifiability of a software system since it easily causes ripple effects [14]. Below you find a list of dependencies, which will be under consideration in this report.

Quality-of-Service If a component is depending on a certain quality of its ingoing or outgoing data then it can affect the modifiability [11]. The demands of each component quality-of-service will for that reason be listed for every component. In the meta model, the quality of service will be an attribute to the component entity.

Functional Dependencies A component, which calls or provides functions to other components, could be difficult modify [13]. Control connectors will be used to model functional dependencies.

Data Flow Dependencies The data flow in the system is another kind of dependence, which can affect the system modifiability [13]. Components could provide or use data owned by other components. The data flow dependencies will be modelled by he data flow connectors.

Syntax Dependencies This type of dependencies can be evaluated by studying data and services between different components [11]. In the meta model, a list of a list of supported protocols will be listed for the entire system.

Semantic Dependencies Semantic coherence has a positive impact on modifiability. The level of semantic coherence can be measured by comparing semantic descriptions of interfaces [11]. Descriptions of a component’s interfaces will consequently be an attribute to every component in the meta model



24

5.4 Aspects of System Changes

The result of a modifiability analysis is depending on what kind of change that is considered [15]. With that information in mind, it is in order to look a little bit closer into some aspects of system changes.

Level of Change There exist different levels of changes namely: local, non-local and architectural changes. A local change affects a component, a non-local change affects components interaction, and an architectural change affects the entire system [15]. It is of course desirable to strive for local changes in favour of non-local and architectural changes.

Component Size There exists several ways of measuring component size. Bengtsson et al. suggest the number of function or object points as well as the number lines of code [13]. The number lines of code is chosen in this case and is an attribute in the meta model. Both the component size and the estimated size of the change will be measured.

Component Owner The owner of a component could affect the level of modifiability of a software system [12]. The more owners the more cooperation is needed to make a successful system change. The component owner could also indicate that the component is used in another system [13]. The component owner will be an attribute in the meta model. The number of system owners/stakeholders will also be summarized on the system level.

Number of Components to Change The number of components to change reflects how easy it is to modify a system [14] and is closely related to the level of change. This variable will be under consideration in the meta model.

Number of Component Versions A change may lead to different versions of a single component, which may increase the difficulties to modify a system [12]. Another version of a component could also exist in another system, which can affect the component owner’s will to modify it [13]. Consequently, the number of versions will be an attribute in the meta model on the system level.



25

5.5 Meta Model

The elements below will be incorporated in the meta model that is based on the theory chapter of modifiability. Please note that the entities only will be modelled for components, which is affected by the change scenario. The meta model is built up by three entities: system, component and connector. The system and component entities also have a list with associated attributes which purpose is to clarify modifiability aspects. The attributes are presented together with its possible values. It is possible that some attributes could not be applied for some particular components.

System Number of system stakeholders: Integer Requirements which affect modifiability: List of requirements Quality goals which affect modifiability: List of quality goals Level of change: Local, Non-local or Architectural Number of components to change: Integer Number of virtual machines: Integer Number components with well-defined interfaces: Integer The number of duplicated components: Integer The number of shared resources: Integer Supported communication protocols: List of protocols Number of systems versions in use (that don’t share the modified components): Integer

Component Type: processes, computational component, passive data repository or active data repository. Owner: Name Component size: Lines of code Estimated change: Lines of code Number of Communication Paths: Integer Interfaces description: List of semantics Quality of service demands which affect modifiability: List of demands

Connector Type: uni-/bi-directional control or data flow.



26

Notation In the figure below is the notation for the entities presented.

Active Data Repository

Passive Data Repository

Data flow

Control flow

Process

Computational Component

System

Figure 14 – Notation



27

5.6 Method of Analysis

The analysis of the system modifiability was based on a change scenario, which is recommended by Bass et al. [26], since a system could be suitable for one type of modification but not right for another type. The change scenario of this study can be read in chapter 7. The purpose of the analysis was to put strengths and weaknesses of the system modifiability into focus. Grading system attributes with a grade 1-3 (where grade 3 was the most excellent.) was the foundation of the analysis. The scale, which was used, is available below. The reason for introducing this scale was the need for a method which puts the values of the attributes into a bigger context. The grading system was not based on any previously known method, which of course could be criticised (see method discussion). Many of the system attributes are derived from the component attributes and that is why the component attributes are not analysed separately.

Number of System Stakeholders Grade 1: >4 stakeholders Grade 2: 3-4 Grade 3: 1-2 Requirements That Affect Modifiability: Grade 1: The requirements have strong negative impact of modifiability. Grade 2: The requirements have medium impact of modifiability. Grade 3: The requirements have low negative impact of modifiability.

Quality Goals That Affect Modifiability Grade 1: The quality goals have strong negative impact of modifiability. Grade 2: The quality goals have medium impact of modifiability. Grade 3: The quality goals have low negative impact of modifiability. Level of Change Grade 1: Architectural Grade 2: Non-local Grade 3: Local Number of Components to Change Grade 1: The change scenario affects many of the identified components. Grade 2: The change scenario affect a medium a amount of the identified components. Grade 3: The change scenario affects few of the identified components. Number of Virtual Machines Grade 1: There are not any virtual machines. Grade 2: There are virtual machines, but the number could be increased in order to improve the modifiability. Grade 3: The amount of virtual machines is high.



28

Number of Components with Well-defined Interfaces Grade 1: There is not any modularisation. Grade 2: There exist modularisation, but the number of components could be increased in order to improve the modifiability. Grade 3: The degree of modularisation is high.

Number of Duplicated Components Grade 1: The number of duplicated components is high. Grade 2: There exist duplicated components but not to any larger extent. Grade 3: There are not any duplicated components.

The Number of Shared Resources Grade 1: The number of shared resources is high. Grade 2: There exist shared resources but not to any larger extent. Grade 3: There exist shared resources to a satisfying extent.

Supported Communication Protocols: Grade 1 None of the existing protocols could be applied for the change scenario. Grade 2: Existing protocols can be used but new ones must be added in order to manage the change scenario. Grade 3: The existing protocols are enough for the change scenario.

Number of Different System Versions in Use Grade 1: >10 Grade 2: <10 Grade 3: None



29

6 Case Study Method

The data collection was performed as a case study during November – January 2006/2007. Two site visits were conducted a few months before the start of the case study. The control centre, the physical power grid and the DMS were explained during a site visit at E.ON Elnät. A theory session was also held at ABB where DMS functionality was demonstrated.

6.1 Sources of Evidence

A case study can, according to Yin [23], be conducted by using the following sources of evidence: documentation, archival records, interviews, direct observations, participant observation and physical artefacts. In this study three of these sources namely documentation, interviews and physical artefacts were used.

Respondents Both of the respondents below are working daily with issues regarding the DMS system and have been deeply involved in the ELDORADO project, which is the name of the E.ON DMS project.

• One system consultant, with 9 years of work experience at ABB e.g. system integrator SCADA/Outage Management System (OMS) and sales representative during the ELDORADO project.

• One system consultant, with 24 years of working experience at ABB e.g. project manger SCADA/OMS integration, technical management and coordination during the ELDORADO project and technical expert during international sale.

In addition, E.ON staff was also interviewed.

• Two DMS operators at E.ON Elnät, Norrköping where one respondent was doing must of the answering.

Physical Artefact One physical artefact was used in this study and that was a demo version of the Network Manger.

Documentation The following documentation was used.

• DMS operator guide (covering DMS functionality)

• NetCADOPS operator guide (covering functionality for handling trouble calls)

• System administrator guide (information about the system architecture)

• Network manager data dictionary (information about the system databases)



30

The documents below were briefly used in order to clarify aspects of other documents or to obtain overall information about ABB systems, which were not a part of the functional evaluation.

• Facil Operator guide (functions for creating outage reports)

• SIS operator guide (covering functionality for planned outages)

• Marketing materials (function descriptions)

• ABB power point presentations (clarifying aspects of the change scenario)

• OMS operator guide (Swedish version of outage management functions)

• NetCADOPS operator guide (Swedish version of trouble call reporting tool) The DMS operator guide and the NetCADOPS operator guide were the main sources of evidences regarding the documentation.

6.2 Data Collection Functional Evaluation

The data collection was performed in order to collect sufficient data, which could be used for describing the current situation regarding the system and its functionality (discussed in chapter 3). In the beginning of the case study, a start up meeting was held where the involved persons at ABB were participating. The aim of the meeting was to explain the overall study method and to get information about which sources of evidence that were available. The DMS and NetCADOPS operator guides were used in order to identify all available system functionality. This functionality was later on modelled using hierarchies, which improved the understandability [29]. The function models were reviewed at two occasions during interviews where the respondent answered questions about the correctness of the model. The questions also addressed what functionality that were installed at E.ON and what new functionality that should be included in the next release of the system. In addition to these two main sessions, during short informal sessions, were also short questions asked about system functionality and architecture. These sessions together with practical use of the DMS and complementary documentation were useful for increasing the understandability of the collected data. A site visit at E.ON Elnät was also conducted in order to identify problems and functional gaps. The questions, which were addressed to the operators, were dealing with their current work process. Much of the focus in this interview was to identify problems with their current way of working. At the time for the visit, a massive storm had just passed a week ago implying that the respondents had a problematic work period in fresh memory.



31

6.3 Data Collection Modifiability Study

The data collection started with a discussion about a suitable change scenario. Interviews with the ABB respondents and discussions with E.ON representatives resulted in the present change scenario. Before electing the change scenario several other scenarios were considered. When the change scenario was established one interview was held with one ABB representative and later on another interview where both respondents (chapter 6.1) were participating. The first interview addressed questions about the values of the elements in the meta model and the second occasion was used for clarifying everything that was unclear after the first interview and for making the data/control flow model. A document which clarified the meaning of the attributes of the meta model were e-mailed to the respondents before the first interview in order to making it possible for the respondents to prepare. In addition to the interviews were the DMS Data dictionary and System administrator guide used to get information about the system architecture.



32

7 Collected Data

This chapter presents the findings of a case study conducted in cooperation with ABB Network Management and will start with a presentation of the outage management process, followed by a description of the system Network Manager DMS (NM DMS) and some particular system functionality important for outage management. This chapter will also be present the collected data of the modifiability study. Much of the data presented in this chapter is classified and that is why there are appendixes, which not are available in the public version of this report.

7.1 The Outage Management Process

Outage management is about handling an outage from the first trouble report to outage restoration. Outages could be reported by phone calls made by customers or non-customers (e.g. a police officer, a fire fighter or maintenance crew). The SCADA system could also detect outages if there is appropriate hardware installed in the power network. The operator could, due to planned maintenance work, also initiate an outage. A description of the current outage management process at E.ON is available in Appendix 3 (a reader unfamiliar with the E.ON systems might consider the next chapter before reading the appendix).

7.2 Network Manager

Network manager is a SCADA/EMS/DMS system which is a merge between different systems where the most suitable functionality is chosen among these systems, depending on the customers need. This study will focus on functions in the three interfaces CADOPS, WS500 and NetCADOPS which are described below. The NM DMS is based on a SCADA system, which supports data acquisition and remote control. The operator interacts with the SCADA system trough a user interface called WS500. The main view in the WS500 is the map view, which either can be a geographic or a schematic view. The geographical view displays graphical information about the power grid. In the schematic view, commands like closing or opening a switch or other SCADA operations can be performed (Appendix 1-2). The outage management functions are accessed by the outage management interface (OMI). Outage information can be viewed or updated in this interface. Such information is for example reported trouble calls or outage information like location and time. The OMI is integrated to WS500 meaning that locations of outages and customers can be displayed in the WS500 maps. Both the OMI and the WS500 are Windows clients running on top of Linux servers and Oracle databases. All OMI functions are executed by the CADOPS system, which is a subset of the NM system. NetCADOPS is a HTML-based web application mainly used by call centre staff for trouble call reporting from both customers and non-customers. All information entered in the NetCADOPS system is also available for the DMS operator which uses information from the trouble reports for fault localization.



33

In addition to these systems/interfaces E.ON also have the following ABB systems installed: Service Information System (SIS) used for planned outages and Facil Operator which is a tool for handling outage history and statistics. ABB also provides E.ON with software for maintenance of the system data like DE400 which is a data engineering tool, the picture editor PED500 and the geographical information system Facil Plus. The systems described in this section (SIS - Facil Plus) are not included in the functional evaluation since they are not much used in outage management process.

7.3 Other E.ON Systems

E.ON also has some non ABB systems for handling outages. The ERP system SAP is used for debiting the outsourced field crews which are doing the field work of the outage restoration. All customer information is also maintained by the SAP system. OJJE is an e-mail client whish is used for sending outage information to radio stations and other media. The Manual Outage Information Tool is used for gathering outage information from CADOPS in order to publish it on E.ON’s web page.

7.4 DMS Functions

The DMS functions are available in Appendix 2 where they are modeled into hierarchies. Appendix 1 contains short descriptions of these functions.

7.5 Identified Problems

Lists of all identified problems in the outage management process are available in Appendix 5. During interviews at E.ON these problems were identified.

7.6 Modifiability

One identified gap regarding the processes of E.ON and the system solution is the lack of integration between the ERP system (SAP) and the DMS. In the present system, the operator manually needs to enter information given by the OMI into a SAP client before creating a service message; such information is the outage location and other descriptive information about the outage. The service message is used for handling order information between E.ON and the field crews, which are outsourced units. The service message is sent by the SAP system to the field crew office. A bill for the maintenance costs is sent back to E.ON after outage restoration. In the figure below the current situation is described.



34

1. The operator uses the OMI in order to find outage information. 2. The outage information is manually entered into SAP and a service message

is created. SAP is sending the information to the field crew office via a middleware.

3. When the work of the field crew is completed a bill for the work cost is sent back to the SAP system.

Figure 15 – Current situation

Change scenario The basic idea behind the change scenario is to make the work of the operator less complicated. This is accomplished by letting the CADOPS system communicate directly with SAP (Figure 16). A prerequisite is that the crew management module is installed in the CADOPS system in order to enable this solution. The operator uses the assign crew function in order to assign a crew to the outage, by doing so a service message is automatically generated and sent to the SAP system. The OMI must be modified in order to display a status of the service message like not sent, waiting and received. If the service message is delayed the operator should be able to continue his work and not be obligated to wait for the confirmation (status received ). When the service message (containing outage information) is received by the SAP system it should respond with a SM_ID, which is unique identifier for the service message. The SM_ID should be stored in the in the CADOPS database so both SAP and CADOPS can keep track of which crew assignment that belongs to each service message.



35

CADOPS SAP

1. Assign Crew

2. getSmId(crewAssignnr,CrewID, deviceID, location)

3. returnSmId(crewAssignNr, smId)

4. Confirmation

23

OMI

1. The operator uses the OMI in order to assign a crew to the outage 2. A service message is automatically created and sent to the SAP system 3. SAP responds by sending CADOPS a SM_ID. 4. The operator can during the process view the status of the service message.

Figure 16 – CADOPS and SAP integration

The data collected which corresponds to the meta model is available in Appendix 7 where the analysis and the result of the study also can be read.



36

8 Analysis and Discussion

The analysis/requirements validation is available in the requirement document Appendix 4. The requirements validation and the problem descriptions in Appendix 5 revealed some functional gaps, which are discussed in Appendix 6. The analysis and discussion of the modifiability study is placed in Appendix 7.

8.1 The Outage Management Process – A Suggestion for the Future

As mentioned before the result of this evaluation cannot be made public. However a discussion of how a DMS should handle an outage can be discussed in general terms and that is what is done in this section. The figure below shows an outage management process, which also is further described. The process does not cover any “what if scenarios”, it exemplifies general DMS functionality that is needed in order to handle a quite normal outage in a good way.

1. AMR outage detection

2. DMS outage analysis

3. Outage prioritising 4. Inform customer

9. Outage restoration

5. Fault isolation 6. Assign crew7. Inform customer

about updated ETR

8. Crew management

10. Outage restoration

confirmation by using AMR

11. Outage termination

Figure 17 –Outage management process

1. Outages are detected by AMR systems, which are installed at every customer location and

are sending data to the DMS. 2. The DMS system analyse the outage information and if several customers are affected the

DMS groups the different trouble reports into one outage report. The DMS also determine the probable outage location.

3. The outage report is presented to the operator in a dynamic list, which is sorted by priority (the priority algorithm is implemented in the DMS and could consider customer type, total outage time, number affected customer and possible danger).

4. The operator acknowledges the outage and outage information is automatically sent to the customer via a SMS service. The information could for example be: “We have discovered an outage at your location. The outage will be restored a soon as possibly and the estimated time of restoration is currently x hours. We will contact you again if the estimated time of restoration changes”. The reason for this message is to reduce the number of calls to the call centre. This information could also be published on a web page or sent by e-mail in order to inform radio stations etc. The estimated time of restoration (ETR) is based on an ETR algorithm, which is provided by the DMS.



37

5. When this specific outage is appearing on the top of the outage priority list (or when the outages with higher priority do not need the operator’s attention) the operator starts the work with this particular outage. The DMS automatically provides the operator with a switching plan, which restores as many customers as possible and isolates the outage. If the switching plan seems reasonable the operator executes it.

6. The next step is to assign a crew to the outage. Available crews are presented in the DMS since the crews have online contact to the DMS by a mobile crew information system. The operator sends an outage order to a selected crew, which responds by using their information system.

7. When the crew are at the outage location they contact the operator via the crew information system and provide the operator with an updated estimated time of restoration. This information is passed on to the customers by SMS, and perhaps web page or e-mail.

8. The crew receives a work proof from the operator. The work proof is presented by the crew information system and is containing information about which parts of the power network that are safe to operate. Perhaps some manual switching is needed which is performed by the field crew (phone contact with the operator could be needed during this activity due to safety reasons). The crew also acknowledges the work proof by using the crew information system.

9. The crew restores the outage and report work completed by using the crew information system. The work proof is returned to the operator and he switches the power back on (possibly by manual switching which the crew conducts).

10. The DMS automatically confirm that all customers have their power back by asking the AMR devices.

11. The outage information is archived in a database, which later on could be used for reports or analyses of the power network. The outage information is also removed from the web page. If the crew is outsourced they could send a bill for the outage work by using the crew information system. The bill is addressed to the company ERP system.



38

9 Conclusion and Further Studies

Below are the conclusion and suggestions of further studies presented. In Appendix 6-7 a more detailed result of the study is available.

9.1 Conclusion

The study has revealed functional gaps, which the ABB DMS has in relation to the outage management process. Consequently, there are potential system improvements, which could be considered in order to better fit the process. Which improvements that should be implemented have to be decided by setting up a strategy for which parts of the outage management process ABB’s DMS should support. Every part of the process that remains uncovered by the ABB system should have standardised interfaces to other systems that can fulfil the process support. The modification that was considered in this report can be accomplished by relative small measures. One of the largest problems is the number of system stakeholders, which must decide the middleware to use. An issue to consider before outsourcing IT is that the number of system stakeholders easily expands by doing so. This can in turn affect the system modifiability.

9.2 Further studies

Some of the problems identified by the system operators were related to interaction design. In a further study, the system interaction design could be evaluated. This study has considered integration between two systems. Information sharing among systems often reveals questions about security. Therefore could a security study be motivated where security solutions and policies are discussed from a DMS perspective. All the suggested improvements (Appendix 6) could also be studied further in order reveal how they could be accomplished more in detail.



39

10 Method discussion

A key issue for conducting the functionality evaluation is to have knowledge in both the system functionality and its surrounding business process. This knowledge was in this study divided and one person dealt with the functionality and one with the business process. I think this approach could be improved by letting both persons participate more in each other’s work, which could lead to important discussions and broader view of the studied subject. This could be a more time consuming approach, which is a possible drawback. The functionality evaluation was only considering the processes of E.ON. However the outage management process is rather standardised among electric power companies and some assumptions about into what extent the ABB system supports the outage management process could therefore be made in a more general perspective. Regarding the modifiability analysis there could be generalised assumptions for similar change scenarios, i.e. similar integrations. Having interviews with more than one person, validate the functionality by using the Network Manager and letting the informants review the collected data were measures taken to increase the construct validity of this study. This report was also reviewed before the final version was approved, which also increased the construct validity. The analysis method is a weak link in the modifiability study since it is not based on theory. It can have problems with reliability since there are some chances that different researchers have different opinions regarding which grade that is appropriate for a system attribute. A measure taken in order to accomplish overall reliability is the method descriptions, which describe the workflow of this study.



40

REFERENCES

[1] Cegrell, T. & Sandberg, U. Industriella styrsystem. SIFU Förlag/Läromedel. 1994

[2] Kundur, P, Power System Stability and Control, Mc Graw Hill, 1993

[3] Cegrell, T.Power System Control Technology. Prentice-Hall International. 1986

[4] Wu. F. et. al. Power System Control Centres: Past, Present and Futire. IEEE, 2005

[5] Cassel, W. et. al. Distribution Management Systems: Functions and Payback. IEEE, 1993

[6] Yusheng, W. Electric Power System Supervisory and Control System For the 21 Century. IEEE, 2000

[7] Xiao, Y. et. al. An Approach to the Integration of GIS and DMS. IEEE, 1998

[8] Kangliaski, T. Power Network Management in Software. IEEE, 2003

[9] Ackerman, W. J. & Block, W. R. Understanding Supervisory Systems. IEEE, 1992

[10] Kazman, R. & Bass L, Toward Deriving Software Architectures From Quality Attributes. Technical Report CMU/SEI-94-TR-10 ESC-TR-94-010, 1994

[11] Stoermer, C. et al. Moving Towards Quality Attribute Driven Software Architecture Reconstruction. IEEE, 2003

[12] Lassing, N. et. Al. Toward a Broader View on Software Architecture Analysis of Flexibility. IEEE, 1999

[13] Bengtsson, PO. Analyzing Software Architectures for Modifiability. Research report 11/00, ISSN 1103-1581, ISNR HK/R-RES-00/11-SE; 2000

[14] Lassing. N. et al. Viewpoints of Modifiability, International Journal of Software Engineering and Knowledge Engineering, 2000

[15] Lassing. N. et al. Experiences with ALMA: Architecture-Level Modifiability Analysis, Journals of Systems and Software, 2002

[16] Lundberg, L. et al. Quality Attributes in Software Architectures Design. Proceedings of the IASTED 3rd International Conference on Software Engineering and Applications, 1999.

[17] Kazman, R. et al. SAAM: A Method for Analyzing the Properties of Software Architectures. IEEE, 1994

[18] Johnson, P. et al. Extended Influence Diagrams for Enterprise Architecture Analysis. Royal Institute of Technology, Sweden, 2006

[19] Dayal, U. et al. Business Process Coordination: State of the Art, Trends and Open Issues. Presented at the 27 th international conference on very large data bases, 2001

[20] Davenport, T. Process Innovation. Harvard Business School Press, 1993

[21] Sommerville, I. Software Engineering seventh edition. Addison Wesley, 2004

[22] Rolland, C. & Prakash, N. Matching ERP System Functionality to Customer Requirements, IEEE, 2001

[23] Yin, R. Case Study Research Design and Methods Third Edition, Sage Publications, 2003

[24] Shapiro, C. & Varian, H. Information Rules, Harvard Business School Press, 1999

[25] Koskinen J. [www] Software Maintenance Costs. University of Jyväskylä, Finland. http://www.cs.jyu.fi/~koskinen/smcosts.htm (viewed 25 October 2006)

[26] Bass, L et al. Software Architecture in Practice. Addison-Wesley, 1999

[27] Metamodel.com [www] What is metamodeling, and what is it good for?, Community site for meta-modeling and semantic modelling, 2002, http://www.metamodel.com (viewed 30 October 2006)



41

[28] Bernhardsen, T. Geographic Information Systems: An Introduction. John Wiley and Sons, 2002

[29] Barker, R. & Longman, C. Case Method – Function and Process Modelling. Addison-Wesley, 1992

[30] Bergvall, M. & Welander, T. Affärsmässig systemförvaltning. Studentlitteratur, 2000

[31] Hammar, E. Modeling the power distribution management process - focusing on outage management. Master thesis, Royal Institute of Technology, Sweden, 2007

[32] Tolis, C. & Nilsson, A. G. Using Business Models in Process Orientation. Published in: Advancing Your Business: People and Information Systems in Concert. Lundberg, M & Sundgren, B (eds.), EFI, Stockholm School of Economics, Sweden, 1996

[33] Mårtensson, A. & Steneskog, G. Business Process Excellence - Some Characteristics. Published in: Advancing Your Business: People and Information Systems in Concert. Lundberg, M & Sundgren, B (eds.), EFI, Stockholm School of Economics, Sweden, 1996

[34] Axelsson, K. & Goldkuhl, G. Strukturering av informationssystem – arkitekturstrategier i teori och praktik. Studentlitteratur, 1998

[35] Goldkuhl, G. Verksamhetsutveckla Datasystem. Intention, 1993

[36] Lucas, H. C. Information Technology and the Productivity Paradox – Assessing the Value of Investing in IT. Oxford University Press, 1999

[37] Falk, T & Olve, N._G. IT som strategisk resurs. Liber Ekonomi, 1996

[38] Davenport, T. H. Putting the Enterprise into the Enterprise System, Harvard Business Review, 1998

pontus karlsson - semantic scholar · 2015-07-29 · flow, temperature and tap changer positions....

Documents