Design of a Corporate SDI in Power Sector Using a Formal Model

Abstract

Geospatial data are essential for the decision-making process. However, obtaining and keeping such data up to date usually require much time and many financial resources. In order to minimize the production costs and incentivize sharing these data, countries are promoting the implementation of Spatial Data Infrastructures (SDI) at the different public administration levels. The International Cartographic Association (ICA) proposes a formal model that describes the main concepts of an SDI based on three of the five viewpoints of the Reference Model for Open Distributed Processing (RM-ODP). Afterwards, researchers extended ICA’s model to describe, more properly, the actors, hierarchical relationship and interactions related to the policies that drive an SDI. However, the proposed extensions are semantically inconsistent with the original proposal. Moreover, the use of ICA’s formal model and its extensions has not been assessed yet to specify a corporate-level SDI. This study describes the merger of actors and policies proposed by the ICA and its extensions in order to eliminate differences in the semantics or terminology among them. This unified model was applied to specify a corporate SDI for a large Brazilian corporation, the Minas Gerais Power Company (Companhia Energética de Minas Gerais (Cemig)), which is comprised of about 200 companies in the power sector. The case study presents part of the specification of the five RM-ODP viewpoints, i.e., the three viewpoints featured in ICA’s formal model (Enterprise, Information, and Computation) and the other two viewpoints that make up the RM-ODP (Engineering and Technology). The adapted ICA’s model proved adequate to describe SDI-Cemig. In addition, the case study may serve as an example of the specification and implementation of new SDIs, not only corporate ones, but also of public agencies at any hierarchical level.

1. Introduction

Geospatial data are those referenced in relation to locations on the Earth and are key to understand the space around, thus being essential to aid in an organization’s decision-making and planning. Some goals and targets of several organizations can only be reached if quality consistent geospatial data are available [1]. As pointed out by Nebert [2], acquiring and maintaining geospatial data are costly processes both in terms of time and in financial resources. In order to minimize such expenses, several initiatives have been proposed to enhance geospatial data usage and sharing, such as the concept of Spatial Data Infrastructure (SDI).

There are several definitions for SDI. Nebert [2] defines an SDI as a collection of technologies, policies and institutional agreements that, by means of a stable and reliable environment, allows geospatial data and its documentation (metadata) to be stored and shared, besides allowing the discovery, visualization and assessment of such data. Harvey et al. [3] consider the SDI “an evolutionary concept that aids in sharing geospatial data and geographic services among different users of a given spatial community.” Finally, Béjar et al. [4] extended the concept proposed by Harvey et al. [3] to state that an SDI “is a federation of communities, which may be other SDIs, in which the communities aim to improve the use, discovery, and sharing of geospatial data in the federation by means of a stable environment”. A community, as defined in [5], is a group of agents that works jointly to reach a common goal. A federation, also according to those authors, is a set of communities.

This study considers an SDI a federation of communities that, by means of a common collection of technologies, policies and institutional agreements, aims to enhance the use, discovery and sharing of geospatial data and services among the communities that are part of it in the face of a stable and reliable environment. Such a definition contemplates the basic high-level components an SDI must have according to Rajabifard and Williamson [1] and Hjelmager et al. [6], represented in Figure 1.

According to Rajabifard and Williamson [1], the components of an SDI are split into the categories Users, Technology and Data, with the category Technology being made up of the components Access Network, Policy and Standards. Hjelmager et al. [6] extend the category Technology to add the components Metadata and Processing Tools. The category Data, now called Products, is formed by the components Data and Services. The definition used in this study and the definition proposed by Béjar et al. [4] highlight the importance of hierarchy among SDIs, with SDIs of different political and administrative levels sharing geospatial data and services among them. SDIs are categorized into levels, so there are Global SDIs, Regional SDIs and Corporate SDIs, among others. Due to several proposals for conceptualizing SDI, Hjelmager et al. [6] state that the SDI concept is very broad and leads to different forms of development both at the organizational and technical level, as also pointed out by Cooper et al. [7]. In order to ensure that future SDIs contemplate the basic concepts in the literature, the International Cartographic Association (ICA) has adopted a model that describes an SDI independently of technologies, policies or implementations [6], which was later extended by Cooper et al. [8], Béjar et al. [4], Cooper et al. [7] and Oliveira and Lisboa-Filho [9].

The Companhia Energética de Minas Gerais (Minas Gerais Power Company (Cemig)) is a mixed-economy company acting in the electricity sector composed of over 200 partners (http://www.cemig.com.br/pt-br/acemig/quemsomos/Documents/Organograma31032015.pdf) and controlled by the government of the state of Minas Gerais (Brazil). Nowadays, Cemig has 127 thousand shareholders in 44 countries. Its shares are traded on the stock exchanges of São Paulo, New York and Madrid. That company seeks to develop an SDI, called SDI-Cemig, to standardize the discovery, sharing and use of geospatial data in the societies that make up the group. With that, it expects to cut down the costs linked to rework in acquiring geospatial data caused by the users (e.g., Cemig employees) not knowing the geospatial data that they need, which already exist. It is also expected that the time spent to treat geospatial data will drop because there are currently no policies determining the minimum quality the data must have at the time of acquisition. Lastly, the SDI-Cemig allows Cemig to tackle in a more efficient way environmental issues. The geospatial data inserted in the SDI-Cemig must follow environmental laws determined by the Brazilian government. This way, Environmental Impact Assessment (EIA) reports can be made with greater quality. According to Cooper et al. [7], ICA’s formal SDI model (referred to as ICA’s model in the remainder of the paper) allows SDIs of any level to be described independently of technologies, policies or implementation using the Reference Model for Open Distributed Processing (RM-ODP). However, no known cases exist of the use of this model to specify corporate SDIs. This way, this paper aims to assess the use of the three viewpoints of ICA’s model (Enterprise, Information and Computation) and the other two viewpoints that make up the RM-ODP (Engineering and Technology) to specify a corporate SDI using SDI-Cemig as a case study. In addition, the paper proposes changes to ICA’s model, besides eliminating inconsistencies between this model and its extensions proposed by other researchers.

The remainder of the paper is structured as follows. Section 2 presents the five viewpoints of the RM-ODP framework, of which three have been adopted by ICA’s formal model. Next, Section 3 presents the specification of the three viewpoints in ICA’s formal model and the other two viewpoints that make up RM-ODP for SDI-Cemig. Some related works are described in Section 4. Section 5 discusses the results obtained in this research. Finally, Section 6 describes the conclusions and some possible future works.

2. RM-ODP Framework

According to Farooqui et al. [10], RM-ODP is an architectural framework standardized by the ISO/IEC (International Organization for Standardization/International Electrotechnical Commission) that is able to describe heterogeneous distributed processing systems by means of five viewpoints: Enterprise, Information, Computation, Engineering and Technology. Figure 2 presents the relationships among these viewpoints. The complete RM-ODP specification can be found in [11,12,13,14].

ICA’s model adopts the SDI viewpoints Enterprise, Information and Computation. According to Hjelmager et al. [6], the Engineering and Technology viewpoints were not adopted due to being too dependent on the implementation details. The concepts RM-ODP proposes for each of the five viewpoints are approached in the sub-sections below.

2.1. Enterprise Viewpoint

The Enterprise viewpoint of the ICA’s model presents instances of the components presented in Figure 1. According to [6], the main components of an SDI are Policies, Connectivity, Technology, Product, Metadata and Processing Tools. The SDI itself is considered the core component, and its attributes are a scope and a plan for its implementation. The component Metadata describes the products (data and services) of an SDI. Moreover, the metadata can be used by the component Product (in this case, the services). The component Product contains the data and services of the SDI, in which the acquisition and use of such data and services is the reason why a user uses an SDI. Therefore, such a component can be considered the main reason for the development of an SDI.

The Product, together with the component Metadata, is used by several external tools, like desktop applications and web services from others SDIs. Such tools are expressed in the component Processing Tools. That component includes tools that use or are used by the SDI to achieve several functions, such as ensuring the working of the SDI by means of a stable environment. To that end, Processing Tools use the component Connectivity to connect to the SDI, which uses a given Technology. Lastly, The component Policies is responsible for establishing restrictions and rules on the SDI itself and on its other components [6].

This viewpoint also describes the actors and their relation among the different parts of the system [6]. The actors are individuals with an interest in the success of the SDI, and they may use it or contribute to it, i.e., individuals who seek to ensure the viability of the SDI. The six actors proposed by Hjelmager et al. [6] were extended by Cooper et al. [8] and Béjar et al. [4]. However, there are inconsistencies, both semantic and in terminology, between the actor roles proposed by Béjar et al. [4] and the actors proposed by the other authors.

Oliveira and Lisboa-Filho [9] unified the actors from the studies by Hjelmager et al. [6] and Cooper et al. [8] with the actors proposed by Béjar et al. [4]. Figure 3 presents the seven main actor roles a participant of the SDI may take on when interacting with it. Each role has a scope and carries out a specific set of functions, and a participant may take on multiple roles simultaneously.

The User consumes the data and services provided by the SDI to reach his or her goals, which is the reason for the creation of the SDI. Different users have different levels of knowledge and ability. Therefore, the User is specialized into Advanced User and Naive User [9]. The Producer is responsible for producing the data and services of the SDI. This actor is classified into four categories (Status, Role, Motivation and Skill), each representing a specific aspect of the actor.

The category Status indicates the level of influence of the producer in the SDI and may be specialized into Official Production Agency, Commercial Production Agency, Community Interest and Crowd Source. The specializations of the category Role (Captor of Raw Data and Passive Producer) indicate the producer’s role in the production of SDI products. The group Motivation is responsible for indicating the reason (Special Interest, Economic, Process) why the producer produces a piece of data and/or service for a given SDI. Finally, the specializations of the group Skill indicate the producer’s skill level, namely from the lowest to highest level: Neophyte, Interested Amateur, Expert Amateur, Expert Professional and Expert Authority [9].

The Provider is responsible for making available in an SDI the data produced by a Producer. Moreover, this actor role has the power to change and remove the data and services it makes available. This actor is specialized as a Producer that is its own Data/Service Provider, Data/Service Distributor and Data/Service Arbiter [8]. The Broker brings together a User that needs some SDI’s product and a Provider that offers such a product and helps the negotiation between the parties. Moreover, it is worth pointing out that the roles related to the catalog are under the responsibility of the Broker, as proposed by Cooper et al. [8]. This actor is specialized into Crowd-sourcing Facilitator, Finder (specialized into Clients/users Finder and Providers Finder), Harvester, Cataloguer and Négociant [9].

The responsibility for adding new functionalities to the existing products of an SDI and making them available as new products is given to the actor role Value-Added Reseller. The Value-Added Reseller is specialized as Publisher and Aggregator/Integrator. The Aggregator/Integrator is specialized according to the product it integrates: Service Integrator and Data and Metadata Aggregator/Integrator [9].

The Operational Body is responsible for ensuring the working, in the technical aspect, of the SDI. This actor role has five specializations: Technical Support, Quality Control, Database Administrator, Submitter of Revision Notice and Gateway Manager. The name of the actor Policy Maker was altered to Governing Body since this actor is not only responsible for the SDI policies, but also for all administrative issues and responsibilities it comprises. This actor role also has five specializations: Legislator, Promoter, Policy Maker, Secretariat and Educator. During the unification, the specialization Legislator did not suffer any changes.

The specialization Policy Maker is in charge of creating, removing or altering policies that govern the SDI. The specialization Secretariat manages the financial resources and has the responsibility of formally interacting with other organizations. The Promoter specialization has the role of promoting the SDI to new users and publicizing to the other members of the SDI the changes it undergoes. The specialization Educator is responsible for the formation and education of SDI members.

Lastly, the policies that manage the behavior and evolution of an SDI are also specified in the Enterprise viewpoint. Hjelmager et al. [6] presented the possible policies of an SDI. Nevertheless, due to the number of policies proposed and the little explanation of each one, the policies by Hjelmager et al. [6] are too generic and ambiguous. This issue was solved by Béjar et al. [4] with a larger number of policies and a more detailed explanation for them. Béjar et al. [4], however, when separating the policies Governance, Membership, Access and Role Assignment of the policy Infrastructure, give the impression that these policies comprise more than the SDI, which is not the goal according to those same authors. This study proposes a reorganization of the policies, as shown in

Table 1. Unification of the policies by the ICA and from the extension by Béjar et al. [4]. Source: [9].

Policies	Specialization
Business Model	Governance
	Membership
	Quality
	Access
	Role Assignment
	Funding
Promotion	-
Standards	Foundation
Education	Best Practices
Constraints	Legal Constraints
	Business Agreements

, with no changes in their names or meanings.

2.2. Information Viewpoint

The information viewpoint describes the system data from their semantics to their behavior. The data in an SDI are defined and regulated by the policies defined in the Enterprise viewpoint [6]. In the case of SDIs, Hjelmager et al. [6] consider as data of the Information viewpoint the products provided by the SDI, i.e., the geographic services and data. Figure 4 shows the UMLclass diagram that describes the relationship of products with the other SDI components.

The class Product, for being the most relevant object in the Information viewpoint, is in the center of the diagram. The class Policies represents the policies defined in the Enterprise viewpoint, which restrict and target the product specifications, represented by the class Product Specification. The products are described by the metadata (class Metadata), and both are registered in catalogs (class Catalogue). The catalogs may contain other catalogs, thus allowing the creation of a hierarchy. The products can be classified into two types: Service and Data (both of which may be geospatial or not). The data are used, aided by previous knowledge, as a source of information, which may generate new knowledge [6].

2.3. Computation Viewpoint

The Computation viewpoint, according to Cooper et al. [7], “is a functional breakdown of the system modeled into a set of objects that interact through interfaces”. When the sets of objects that make up the system are modeled in this viewpoint, the designer should not take into account the physical distribution of the objects since that must be detailed in the Engineering viewpoint. The interfaces of the computational objects must have a signature, a behavior and an environment contract [7]. In order to simplify ICA’s model, the behavior of the components’ interfaces was modeled using the provided and required interfaces of the diagram of UML components, as exemplified in Figure 5, whereas the signatures and environment contracts were not described [7].

Six computational objects required by an SDI were identified by Cooper et al. [7]: SDI Data, SDI Portrayal, SDI Registry, SDI Processing, SDI Application and SDI Management. Each of those computational objects uses and provides a set of functionalities by means of interfaces. In [15], the authors discuss and revise the interfaces of the components proposed by Cooper et al. [7]. Therefore, the components to be described are based on the proposal by Oliveira et al. [15]. Figure 5 presents the interfaces of the components in the Computation viewpoint with their possible relationships. The connectors with a circle are provided interfaces, i.e., the functionalities provided by the components, while the connectors with an arch are required interfaces, i.e., the functionalities the component needs to carry out a task and that are provided by other components.

The component SDI Registry is responsible for storing and registering the products (data and services), catalogs, metadata, product specifications and SDI policies, besides allowing them to be searched. This component has a single required interface, SDI Management::Control, and three provided interfaces. As in [7], the notation “::” is used to indicate the interfaces of a component. Since all components use the SDI Management::Control interface, the explanation for this interface will be omitted when the other interface required from a component is described. The SDI Registry::Register interface is responsible for providing the functionalities of the information an SDI may have. The SDI Registry::Search interface searches for the information required by users by means of the catalogs registered in the SDI, while the SDI Registry::Publish interface publishes the information registered on the Internet and other media, which allows the user to search for the information registered in the SDI [7,15].

The component SDI Data is the only one with direct access to the database and is responsible for delivering the data that the users search for. Since it only carries out this function, the component does not need to register or publish the data. This component has two provided interfaces: SDI Data::Data Delivery, responsible for sending the data requested by the SDI Application and SDI Processing components; and SDI Data::Data Manipulation, responsible for manipulating (creating, updating and removing) SDI data [15]. The SDI Processing component is responsible for processing SDI data, containing services such as transformation of geographic coordinate systems, data analysis and coordinate processing. SDI Processing has a single provided interface, SDI Processing::SDI Service Delivery, which allows the other components to use the processing services provided by the component. This component uses the following interfaces: SDI Data::Data Delivery to obtain the data used by processing services; SDI Registry::Publish and SDI Registry::Register to automatically publish and register new geospatial data generated by processing services; SDI Registry::Search, used to search for new data whenever needed; and SDI Data::Data Manipulation, responsible for manipulating SDI data.

SDI Portrayal returns the geospatial data searched for, such as maps, i.e., as static images when used by the services of the SDI Application component, with a single provided interface, SDI Portrayal::Portrayal Delivery. The component SDI Application is considered by Cooper et al. [7] the main SDI component and is the only component accessed by the user. The component SDI Application must take on the responsibility of registering or publishing the map returned by SDI Portrayal if the user so wants. In order to meet all user needs, SDI Application has several required interfaces, using at least one interface of each of the other components, as shown in Figure 5, and has no provided interface. The last component is SDI Management. This component guarantees the proper working of the other components, such as ensuring interoperability among services and access rights of each user.

2.4. Engineering Viewpoint

This viewpoint aims to identify and specify interactions among distributed objects, focusing on their communication, organization and distribution. It comprehends the distribution of components and the links among them, besides defining common support functions in the component distribution [16]. This sub-section presents some of the components that are part of the Engineering viewpoint that are used in the remainder of this paper. The Basic Engineering Object (BEO) corresponds to the smallest representation in the specification of modeling within the Engineering viewpoint. It is a special type of object that represents a computational object defined in the Computation viewpoint that may also represent a system agent. In short, BEOs represent abstractions of elements that are part of the system.

Figure 6 illustrates the organization of objects in the Engineering viewpoint and shows a hierarchy among the objects. For example, a Node represents a set of capsules; a Capsule is made up of several clusters; and a Cluster comprises several BEOs. A cluster consists of a collection of grouped BEOs with similar functions that have life cycles in the system. A capsule represents a unit independent of processing and storage that is able to support a collection of objects. They are isolated among themselves to ensure that issues in one capsule do not directly interfere in another [16].

The Node element represents a physical or virtual object that has processing, communication and storage capacity. It may represent a computer, the union of several devices that together determine a unit or a virtual machine in a computer, as long as the element has the aforementioned capacities. They are also highly isolated [5]. The component structure in the Engineering viewpoint is split into components isolated from the capsule element. Thus, mechanisms must be used in the communication among elements that are in remote structures. To that end, a communication channel structure is used [17].

Communication channels represent a seamless communication infrastructure that allows objects in the Engineering viewpoint to interact and are commonly used in the communication among BEOs of different nodes. Often, a channel need not be specified in detail as it is implemented at a lower level, while the channel’s goal is to represent a communication among elements [16].

2.5. Technology Viewpoint

The Technology viewpoint provides a view in terms of software and hardware when building the system, minimum technology requirements, as well as the evolution of its useful life [16]. This viewpoint represents a concrete view of the components created in the viewpoint seen earlier with the goal of describing the components that receive the products and technologies for implementation, as well as allow component adequacy to be verified [18]. ISO/IEC Norm 10746-3:2009 [13] describes the following structures to be used in the creation of the technology viewpoint: technological object, implementation standards and Implementation Extra Information for Testing (IXIT).

The technological specification is based on the use of technological objects, components that abstract a piece of hardware or software to be used in the system implementation [5]. According to Wnuk et al. [19], constant advance can be seen regarding compatibility among different technologies. However, there are still technologies that are incompatible among themselves. Due to this possible incompatibility, the viewpoint must be specified with schema relating the set of components and technologies employed to verify the system’s compatibility and performance [5]. Aiming to meet this demand, the RM-ODP framework instructs the definition of implementation standards for the project, a diagram in which the technologies employed are specified related to their respective technological objects [13]. For greater visibility among components and technologies, a diagram is used that relates technological objects and the technologies they use. Figure 7 illustrates a representation of technological objects with their respective technologies.

It shows a simple network interconnecting components. The “Remote System” component, represented by an icon similar to a computer, uses a browser with HTML4 technology with access to a printer object with laser printing technology. For a print job, the computer must use an ADSLWide Area Network (WAN) as a means of communication and then communicate with the printer’s Local Area Network (LAN). In order to perform this communication, access is controlled by a firewall that validates the access permission by the computer to the printer.

Technological objects may be followed by basic information to be verified in their implementation and testing. To add this content, the RM-ODP standard used the IXIT concept. IXIT contains extra information that guides the implementation of the project to check for its basic working needs. Its elaboration consists of text elements attached to the technological objects to be specified [16].

3. SDI-Cemig

As described in Section 1, Cemig, aiming to cut down rework costs in the acquisition and maintenance of geospatial data, has decided to implement an SDI, called SDI-Cemig, to standardize the discovery, sharing and use of geospatial data in the several societies that make up the group. Cemig has geospatial data that comprehend virtually the entire Brazilian territory, and the costs of obtaining such data justify the implementation of SDI-Cemig.

The model adapted from the ICA was used to specify SDI-Cemig so as to guarantee that the basic SDI concepts in the literature would be considered during the specification phase. The sub-sections below describe part of the specification of the three viewpoints of ICA’s model (Enterprise, Information and Computation) besides the other viewpoints of the RM-ODP framework (Engineering and Technology) that were applied during the specification of SDI-Cemig.

3.1. Enterprise Viewpoint

As described in Section 2.1, the ICA’s model adopts the components that make up an SDI and the possible actors that may interact with it. The components and communities and their roles in SDI-Cemig are detailed ahead.

3.1.1. SDI-Cemig Components

The scope of SDI-Cemig is to make available online a set of geospatial layers considered essential to the companies in the electricity sector and that may be used by Cemig’s employees and clients, besides offering services to visualize and discover geospatial data. The implementation plan of SDI-Cemig was provided to the public and to other companies in the electricity sector by the end of the SDI’s development. Figure 8 illustrates the class diagram for the Enterprise viewpoint, proposed by Hjelmager et al. [6], which was used as base for the specification of components in SDI-Cemig.

The component Product is made up of SDI-Cemig’s geospatial data and services. As for the data, the geospatial layers in SDI-Cemig are considered basic for Cemig to work, i.e., they are relevant geospatial layers for the electrical grid maintained by Cemig to work. Such data are further detailed in the Information viewpoint (Section 3.2).

SDI-Cemig must provide services for the discovery, visualization and recovery of geospatial data, which must be compatible with the OGCstandards. The use of services based on OGC standards allows SDI-Cemig to interact with other SDIs at different levels. SDI-Cemig has no processing service able to produce new geospatial data at first. The SDI products are described by metadata, which are specified according to the Brazilian Geospatial Metadata (MGB) profile [20]. The metadata may be used by the Processing Tools to help discover new geospatial data and services and to obtain relevant information on them. In SDI-Cemig, the Processing Tools are the legacy systems and desktop applications that use the SDI’s geospatial data and services.

The component Connectivity specifies how the Processing Tools interact with the SDI, which is possible by using a Technology. The legacy systems and desktop applications at Cemig interact with SDI-Cemig by exchanging files in the XML format using the GMLstandard as the schema [21]. Besides the use of files, the desktop applications may interact with SDI-Cemig through web services in case they are supported. The policies of SDI-Cemig were categorized according to the specializations of SDI policies after the unification. It is noteworthy that several policies in the specialization Standards were taken from [2] so as to help SDI-Cemig interact with other SDIs, particularly at the national and regional levels, such as the policy “The transport of geospatial data will be in XML format using the GML schema.”

3.1.2. Communities and Their Roles in SDI-Cemig

The possible roles the communities may take on in SDI-Cemig were adapted and unified by Oliveira and Lisboa-Filho [9] and are used to specify the several communities that interact with the SDI. For example, Figure 9 illustrates the community Committee, specified for SDI-Cemig. The community Committee is formed by members of different sectors at Cemig, represented by the communities Representative, such as Information Technology (IT) and the sectors Generation, Transmission and Distribution, and its role is to define the working of certain processes carried out by these sectors. Hence, the Committee takes on the roles of Legislator, Secretariat and Policy Maker and is responsible for all of SDI-Cemig’s administrative area.

The community GIS Analyst represents the IT individuals with positions homonymous to the community, who are responsible for carrying out and analyzing the procedures performed in a Geographic Information System (GIS) to manipulate geospatial data. The GIS Analyst may take on the roles of Data/Service Distributor, Data and Metadata Aggregator/Integrator and Négociant. The community is responsible for providing the geospatial data and services produced by the Producers in SDI-Cemig. Moreover, the community is also responsible for purchasing the geospatial data the users require, thus acting as a Négociant. Finally, the GIS Analyst, when carrying out procedures on the geospatial data in a GIS, is able to generate new geospatial data or to expand existing data, thus taking on the role of Data and Metadata Aggregator/Integrator. Moreover, the IT is in charge of creating and maintaining the catalogs of data and services made available by SDI-Cemig by using user-produced metadata.

Cemig has several sectors that act in the processes of electric energy generation, transmission and distribution. The generation process consists of the generation of electricity through power plants, and Cemig has hydroelectric, thermal, wind and solar plants. Transmission consists of a network that carries the energy produced by the power plants to the large consuming centers. Finally, the distribution is the network that supplies energy to small- and medium-sized companies and to residential consumers [22]. Therefore, the groups generation, transmission and distribution were created. Given the large number of sectors related to each group, they are represented by the communities Generation, Transmission and Distribution. Besides these communities, each group has a Geospatial Data Manager and a Representative. Each group has its Spatial Data Manager community, which is responsible for guaranteeing data consistency for each group; hence, it takes on the role of Database Administrator. However, it must be pointed out that Cemig has a position called Database Administrator, although its role is different from the one defined by Cooper et al. [8]. At Cemig, this position is in charge of guaranteeing that the database and the hardware supporting it are in order.

The community Representative is a generic community used to illustrate the individuals that represent the interests of each group in the community Committee. Finally, each group has a homonymous community (Generation, Transmission and Distribution) that represents the different sectors at Cemig that work directly or indirectly with the data of that group. The communities Generation, Transmission and Distribution are considered Official Production Agencies. These communities are also responsible for publicizing the data they produce in the SDI, thus taking on the role of “a Producer that is its own Data/Service Provider.”

SDI-Cemig interacts with other communities other than the ones within Cemig, i.e., other SDIs and organizations. The community of the Instituto Brasileiro de Geografia e Estatística (Brazilian Institute of Geography and Statistics (IBGE)) is the federal public organ that produces nationwide geospatial data, besides being responsible for defining the standards to be used by the other geospatial data-producing organizations, thus taking on the role of Producer. The data produced by the IBGE are publicized through the Infraestrutura Nacional de Dados Espaciais (National Spatial Data Infrastructure (INDE)). SDI-Cemig interacts with INDE and fetches the data available using web services, which makes INDE a Provider of SDI-Cemig. Besides INDE, SDI-Cemig obtains and provides information to the Sistema de Informações Geográficas do Setor Elétrico (Geographic Information System of the Power Sector (SIGEL)) of the Agência Nacional de Energia Elétrica (National Electric Energy Agency (ANEEL)). ANEEL is responsible for regulating and overseeing the Brazilian electric energy market to ensure that companies working in the country follow the regulations in effect. SIGEL is a system that allows the visualization and acquisition of some geospatial data made available by the utility companies to ANEEL. Therefore, ANEEL takes on the role of User in SDI-Cemig by retrieving the data through the GeoPortal or through web services, while the SIGEL takes on the role of Data Provider by making available to SDI-Cemig the data provided to ANEEL by the other utility companies.

3.2. Information Viewpoint

As well as in the Enterprise viewpoint, the components defined by Hjelmager et al. [6] for the Information viewpoint, shown in Figure 4, are identified in SDI-Cemig. According to Hjelmager et al. [6], the model presented in that figure begins with the component Policies, which defines the basic geospatial data (layers) the SDI must have, besides allowing the link with the Enterprise viewpoint. The basic data of SDI-Cemig are described in the policies Foundation, which, due to space constraints, are not presented in this paper. Moreover, the policies define any restraint that the geospatial can have, be those restraints imposed by Cemig norms (e.g., all geospatial must be in a specific geographic coordinates system) or laws from the government (e.g., environmental laws). Due to privacy issues, those policies will also not be presented. It must be pointed out that much of the data in SDI-Cemig are related to electricity generation, transmission and distribution. The members of SDI-Cemig may request new products (data and services) by opening a ticket with Cemig’s help desk, being limited by the policies. Such tickets are considered the products’ specifications (component Product Specification).

The Products are described by Metadata, which allow the users to assess whether the product meets their needs, besides facilitating searching for them. Both Metadata and Products are recorded in a Catalog to aid in their discovery. The catalogs are created according to the topics of the geospatial data offered by SDI-Cemig such as hydrography, generation, transmission, distribution, infrastructure, etc. According to the model in Figure 4, data generate information based on pre-established knowledge. In SDI-Cemig, data are used to generate information used by the different sectors at Cemig through reports and maps. Such information is generated based on the knowledge of employees specialized in geoprocessing, usually Geoprocessing Analysts.

According to Béjar et al. [4], the policies of the type Foundation define the basic data and services that the SDI must have. However, the alone database description is not able to show the relationship among the data or how they behave in the system, which is one of the goals that the Information viewpoint aims to represent [5]. Figure 10 shows the conceptual schema of the database adopted by SDI-Cemig. In order to create the schema, the extended UML class diagram was used with the primitive types of the OMT-Gmodel [23]. The package Distribution Grid has layers related to Cemig’s regional distribution grid and layers that help manage this grid. The packages Generation, Transmission and Distribution contain the classes that represent the elements that make up the electric grid administered by Cemig. In [24], a detailed description of each of those packages can be found.

3.3. Computation Viewpoint

The set of applications and services to be used by SDI-Cemig has not been defined yet; however, it has been defined that any applications to be developed must be compatible with the OGC standards. Thus, the following generic names are used to represent the components of SDI-Cemig: Portrayal SDI-Cemig, Data SDI-Cemig and Catalogue SDI-Cemig. It is important to point out that the term “component” used in this section has different semantics than the one used in Section 3.1. In this section, the term refers to the instances of the computational objects defined in the Computation viewpoint (Section 2.3). The component Portrayal SDI-Cemig implements the WMS standard. The component Data SDI-Cemig is in charge of accessing the geospatial data of SDI-Cemig, with the ability of recovering, inserting, altering and removing those data, implementing the WFS, WFS-G and WCSstandards. Finally, the metadata and catalogs are managed by Catalogue SDI-Cemig through the implementation of the OpenGIS Catalogue Service standard. Just as the component Data SDI-Cemig, Catalogue SDI-Cemig is able to recover, insert, update and remove the catalogs and metadata from SDI-Cemig’s database.

In SDI-Cemig, the component SDI Application is equivalent to the geoportal, and its goal is to serve as an access point to the SDI’s users, features and data, which are provided by the geospatial services. In line with the specification of the computation object SDI Portrayal (Section 2.3), the component Portrayal SDI-Cemig has a single provided interface that is responsible for providing a graphical representation, i.e., a map, that represents the data provided to the component. The component SDI Application is responsible for using the interfaces of the SDI Registry in case the user wishes to register or publish the data represented.

The access and direct recovery of data from the SDI, a responsibility of the component SDI Data, are similar, in SDI-Cemig, to the component Data SDI-Cemig. This component has interfaces that allow the geospatial data requested to be fetched, with different ways for this query to be performed. By using the interfaces standardized by the WFS, the component Data SDI-Cemig recovers geospatial data by spatial queries, whereas, using the interfaces standardized by the WFS-G standard, such data are recovered using a geographic dictionary called the gazetteer. However, neither of those standards specify interfaces able to recover geotagged images, a feature that is under the responsibility of the interfaces standardized by the WCS standard. As with the interfaces implemented from WFS, Data SDI-Cemig implements the interfaces from WCS, which allows geotagged images to be recovered by spatial queries.

The component Catalogue SDI-Cemig in SDI-Cemig is the equivalent of the computation object SDI Registry. Catalogue SDI-Cemig has interfaces to record and search the catalogs and their records through the implementation of interfaces specified by the OpenGIS Catalogue Service. However, the interface SDI Registry::Register ensures that the catalogs and their records are inserted or updated in the database, but do not guarantee their availability to users. In order for a catalog or record to be available to users, either through the Internet or Intranet, the interface SDI Registry::Publish must be used. However, Catalogue SDI-Cemig has no specific interface for this task, which requires the application or service compatible with that standard to be adapted. That can be achieved by adding a new interface or functionality, which is equivalent to the interface SDI Registry::Publish or by changing the behavior of the interface SDI Registry::Register, which makes new catalogs or records automatically available to users when they are registered.

SDI-Cemig, at first, will not provide geoprocessing services since its focus is to facilitate sharing geospatial data of interest of Cemig’s employees and clients. Moreover, SDI-Cemig has no specific component to deal with the management of data access rights or to ensure integrity and compatibility of geospatial data when exchanging messages among the interfaces. Access rights management will be the responsibility of the Geoportal, whereas the guarantee of data integrity and compatibility will be the responsibility of the components themselves. Hence, SDI-Cemig has no components equivalent to SDI Processing or SDI Management. In [15], the components identified in SDI-Cemig and their interactions through computational objects are presented in greater detail.

3.4. Engineering Viewpoint

The overall organization of the specification of the Engineering viewpoint for SDI-Cemig is shown in Figure 11, which contains the elements grouped according to the functionalities of their objects. The overall organization represents a global view of the components in the Engineering viewpoint, which, in the case of SDI-Cemig, is split in two: NV Objects and ObjectsDistribution. The division NV Objects groups objects that represent basic elements, represented by BEOs, which as grouped into packages that have similar features. The objects may be grouped into four packages: HumanBEOs, ApplicationBEOs, PresentationBEOs and DataBEOs. The package HumanBEOs includes the roles that are part of the application, defined as: User, Supplier, OperationalBody and Cataloguer. In the package PresentationBEOs, the BEOs represent the interfaces for the actors included in the package HumanBEOs. Its nomenclature has the prefix GUI2 (Graphical User Interface 2) added, plus the corresponding name from the package HumanBEOs. Therefore, the components of the package PresentationBEOs were described as: GUI2User, GUI2Supplier, GUI2OperationalBody and GUI2Cataloguer.

The package ApplicationBEOs represents the features the actors in SDI-Cemig may use in its working and administration. They represent three functions found by Oliveira et al. [15] that are required for SDI-Cemig to work. Its nomenclature is added with the suffix Ops (Operations) in each of its components. The components created were PortraitSDICemigOps, DataSDICemigOps and CataloguerSDICemigOps. Finally, the package DataBEOs has BEOs related to information from the database. The package has components with responsibilities in data storage and management. In its nomenclature, the suffix DataMgr (Data Manager) was adopted, as seen in Figure 11.

The division ObjectsDistribution has components that represent the logical distribution and communication. It comprises two packages: Nodes and Channels. The package Nodes represents a set of node elements defined for the system. For SDI-Cemig, four nodes were defined: UserPresentation, AdministrationPresentation, CoreCemig and ManagementDataCluster0. In the nomenclature of the package Channels, the suffix Chl (Channel) was used. The package’s purpose is to carry out the communication of the components since the nodes are isolated and require a medium to communicate. The following channels have been defined: PortraitSDICemigChl, DataSDICemigChl, CatalogSDICemigChl and StockSDIChl. Torres et al. [25] present further details on the distribution of the Engineering objects in SDI-Cemig.

3.5. Technology Viewpoint

For this viewpoint, a diagram was created consisting of nine technological objects representing firewalls, networks, servers and system users, as illustrated in Figure 12. Its specification is based on the requirements described by the previous viewpoints. The element RemoteSystem represents a system user that intends to access SDI-Cemig. To that end, the user has two interfaces, namely a web browser and services for communication with traditional geographic information handling software (e.g., GIS, image processing). There are two technological objects representing firewalls controlling the access to the system. The first element (ExternalFirewall) consists of a protection against external invasions and unauthorized access, controlling all connections among the servers of the CemigLan network with computers located in WAN external networks. The second firewall (InternalFirewall) consists of extra information access protection to the component DataServer, a server containing geographic information that is managed by a database with spatial extension. Its creation is a norm by Cemig, which requires extra protection for access to the geographic data storage server [26].

The other technological objects represent four servers responsible for several functions in the system. They are made up of the following components: PortalCemigServer, MapsManagerServer, CataloguerServer and DataServer. MapsManagerServer is the servers in charge of generating a graphical visualization of data using information provided by the object DataServer. It must answer queries via the web browser and web services. CataloguerServer is the server that provides the catalog on geographic information available to the user in the database. The information must be provided along with their metadata, which follow the MGBprofile [20].

Finally, the object PortalCemigServer consists of a server whose responsibility is to provide a web interface to the Remote System object, whose interface allows access to the following system functionalities for the Engineering viewpoint: PortraitSDICemigOps, DataSDICemigOps and CatalogSDICemigOps. In order to meet those needs, the server communicates with the objects MapsManagerServer to generate maps, CataloguerServer to obtain a data catalog and DataServer to obtain the geographic data from the geographic information database. PortalCemigServer is responsible for the navigation interface, using technologies that can be implemented on a website (e.g., OpenLayers, AngularJS). To that end, the technologies chosen are familiar to and preferred by the company’s technical staff [26].

In order to build the internal components of the servers PortalCemigServer, CataloguerServer and DataServer, which have specialized purposes, technologies suggested by Fonseca et al. [27] were chosen, which are in accordance with the restrictions imposed by Cemig. The server PortalCemigServer contains the components PresentationWeb and Control. The component PresentationWeb represents the system visualization layer, with the use of the AngularJS (https://angularjs.org) framework being proposed for its construction. The Ruby on Rails (http://rubyonrails.org) framework was assigned to the component Control. To the servers MapsManagerServer, CataloguerServer and DataServer, the software MapServer (http://www.mapserver.org), GeoNetwork (http://geonetwork-opensource.org) and PostgreSQL (http://www.postgresql.org), respectively, were assigned. Those software packages, according to Fonseca et al. [27], are quite adequate as components in the construction of SDIs. Aiming to meet the need to replicate data from the Engineering viewpoint, the server DataServer uses the technology Redundant Array of Independent Disks (RAID) for the component Storage [28]. The component RemoteSystem has the element BrowserRequest, which is represented by a browser using Hypertext Markup Language 5 (HTML5) to access the system via the web. The component ServiceRequest represents software that uses the communication standards WMS and WMF and standards for access to geographic information by services so that the components are compatible with several GIS and map servers [27]. The components CemigLAN, WAN, InternalFirewall and ExternalFirewall have no extra specification as they are established standards representing networks and firewalls. The IXIT diagram of SDI-Cemig’s model has also been defined, and its details are presented by Torres et al. [29].

4. Related Works

This section describes some works that report prior experiences with SDI projects based on ICA’s model. The models mentioned in this section were highlighted by Cooper et al. [7] and were used to describe a regional SDI (INSPIRE for the European Union) [30] and national SDIs (Canada, Namibia and Ghana). Although Sjoukema et al. [31] describe two SDI projects that were financed by utility/power companies, no experiences of corporate-level SDI projects were found.

4.1. SDI Description Model for INSPIRE

The project Infrastructure for Spatial Information in the European Community (INSPIRE) [30] uses its own SDI architectural model [32], which includes the description of services available and how those services interact with the applications, portals and other services. INSPIRE offers five types of services, which are the architecture’s core: Discovery, Vision, Download, Transformation and Invoke.

The Discovery services aim to discover services and geospatial data based on the description of their metadata, besides showing the metadata content. The Vision services are responsible for exhibiting the geospatial datasets with some basic features such as zoom, navigation, geospatial data overlapping, displaying legends and relevant information contained in the metadata. The Download services allow geospatial data to be downloaded partially or in full. The Transformation services convert geospatial data into different geographic coordinate systems so as to ensure data interoperability. The Invoke services allow different types of geospatial services to be invoked. Moreover, the Invoke services allow services to be invoked individually or sequentially, as several services are invoked in a given order to reach the user’s goals.

The architecture used to describe the services in INSPIRE is based on the service-oriented architecture, in which services are consumed and provided by means of a service bus. To ensure interoperability among services, particularly among the services developed by the different members of INSPIRE, the Network Services Drafting Team [32] determined that the messaging protocol among the services is the Simple Object Access Protocol (SOAP). One of the reasons for adopting SOAP was the recommendation by the World Wide Web Consortium (W3C) to use it as the messaging protocol for web services.

4.2. SDI Description Model for CGDI

GeoConnections [33] abstractly describes the architecture used to develop the Canadian Geospatial Data Infrastructure (CGDI). The paper briefly describes the motivation and objectives for the development of the CGDI and its four main components: Data (geospatial or otherwise), Services, Applications and the main Users that interact with the SDI.

Data is the main component of the CGDI and is responsible for managing geospatial and relational data. In order to ensure duplicated data are minimized and improve the interoperability among the existing data, the component Data uses three data layers: alignment layer, land feature layer and conceptual layer [33]. The alignment layer was geometric “controls” that allow the geospatial data of the other layers to be properly positioned. The land feature layer has well-defined and easily observable geospatial information, with no room for ambiguity, such as roads, rivers, lakes and elevations, unlike the conceptual layer, which represents social, economic and physical phenomena such as borders and ecological areas.

The component Services consists of web services that allow geospatial data to be easily accessed and shared. In order to ensure the interoperability of web services, the CGDI implements and incentivizes the web service standards defined by the Open Geospatial Consortium (OGC) and by ISO/TC 211 [34].

The Applications, which use one or more web services, are a way for the user to access and use the geospatial data available in the CGDI. Some types of applications were generalized and classified into four categories: Viewer Clients display geographic data graphically to the user; Discovery Clients allow geospatial data available in the CGDI to be queried; Publisher Clients are data providers that may define how the geospatial data are distributed; and Editor Clients can add, edit and remove geospatial data in the CGDI.

CGDI Users were grouped into four categories: Suppliers are responsible for adding new geospatial data and web services to the CGDI; Developers are users who develop the applications used by the end-user to access the CGDI; Marketers are responsible for selling and supporting the applications used to access the CGDI, also helping to publicize it; End-Users are the main beneficiaries of the CGDI and use the geospatial data available to reach their goals.

4.3. Use of ICA’s Model to Develop Namibia’s National SDI

Namibia launched its spatial data infrastructure to improve the sharing and use of geospatial data and services within the country. The goals of Namibia’s SDI are to improve the acquisition, use, management, maintenance and sharing of geospatial data used by Namibia by creating an environment that enables coordination and collaboration among users of the SDI regarding the use of such data, which aids its use in support of socioeconomic planning and decision-making. Moreover, the SDI also aims to eliminate duplicate geospatial data and help manage and oversee copyrights of works that use geospatial data [35].

According to Sinvula et al. [35], several models were analyzed to help develop Namibia’s SDI. A model with generic geospatial databases, standards and formats based on existing policies and standards was sought. The model chosen was RM-ODP due to its alignment with the proposal of SDI with a business viewpoint of the model “in the realm of the proposal, of the standards and policies for an SDI system that facilitates the acquisition, management, maintenance, integration, distribution, and use of spatial data”.

Sinvula et al. [36] identified the stakeholders in Namibia’ SDI, which is at an early stage of development, based on the actors identified by ICA’s SDI model proposed in [8], and all official mapping agencies, commercial mapping agencies, communities of interest and sources of information are considered Captors of Raw Data. Since Namibia’s SDI was at an early stage at the time of publication of the present paper, all data producers of the SDI take on the responsibilities of the actor Database Administrator. Regarding the actor Producer, Namibia’s SDI does not have the actors Beginner or Interested Amateur.

Sinvula et al. [36] conclude that the ability level of all stakeholders that take on the actor roles Special Interest and Information Source is of an Expert Amateur, although, during the development of the work, the authors stated that there was no Expert Amateur in Namibia’s SDI. Finally, Namibia’s SDI has a deficiency concerning stakeholders related to the SDI services, as there is none that takes on the roles of Service Distributor, Service Arbiter or Service Integrator.

Nambibia’s SDI, however, has not been fully adopted in all potential areas of the Namibian government. In [37], the author reports that geospatial data related to biodiversity in Namibia present several problems, rendering ineffective their use for EIA. One of these problems is that the biodiversity geospatial data in Namibia are not maintained by government organizations but by Non-Governmental Organization (NGO), universities (e.g., University of Cape Town) and quangos (research institutes funded by the government). Due to this, there is no guarantee that geospatial data concur with the policies specified in Namibia’s SDI. This leads to the others problems listed by [37]. According the author, “none of the identified geodatabases matches the vector format, spatial resolution, output format and/or comprehensiveness requirements of EA”.

Although the biodiversity geospatial data found by [37] are not suitable to use for EIA, it is important to highlight that the Namibian government does not have any data related to this area. Therefore, we can conclude that the application of Namibia’s SDI policies in the biodiversity geospatial data could improve their quality and facilitate their use for any organization or user that would be interested in them. Moreover, the existence of NGOs with relevant data for the government, although not detailed in this work, was not considered by [36]. The consideration of NGOs as possible Producers and Providers in Namibia’s SDI can provide a great quantity of relevant geospatial data that can cover areas for which the government does not have much or any data.

4.4. Using ICA’s Model to Specify Ghana’s National SDI

Ghana launched a national SDI to improve the sharing and use of geospatial data in governmental organizations. Ghana’s SDI is at an early stage of development and is the second initiative in that country regarding SDIs. The first initiative, the National Framework for Geospatial Information Management (NAFGIM), is currently inactive [38]. Owusu et al. [38] used ICA’s SDI model to identify the actors in the NAFGIM when it was working, with the goal of understanding why it was unsuccessful and avoiding repeating the errors in Ghana’s SDI. Those authors used the same method adopted by Sinvula et al. [36].

The results were similar to those obtained by Sinvula et al. [36], in which the NAFGIM, concerning the actor Producer, has no stakeholders with the role of Community of Interest and Source of Information, besides not having Producers with Beginner or Interested Amateur ability levels. Moreover, the NAFGIM lacked stakeholders related to the services of the SDI, with none that took on the roles of Service Distributer, Service Arbiter or Service Integrator [38].

Owusu-Banahene et al. [38] conclude that the new stakeholders should exist in Ghana’s SDI to take on the responsibilities of the actors that were not used in the NAFGIM and that many of the stakeholders will be maintained in the new SDI. In addition, the authors criticize ICA’s SDI model proposed in [6,8] because it is not able to represent all actor roles in the SDI. Owusu-Banahene et al. [38] points out the lack of an actor related to the production of services in the SDI. Several deficiencies highlighted by Owusu-Banahene et al. [38] in ICA’s model were corrected by Oliveira and Lisboa-Filho [9], as shown in Section 2.

5. Discussion of the Results

Using the RM-ODP framework as a model for the implementation of complex distributed systems, as is the case of an SDI, allows the system to be described at different levels of abstraction, besides allowing the specification of characteristics such as distribution, interoperability and portability using a technology-independent language. The use of ICA’s model for SDIs, developed by Hjelmager et al. [6] and extended by Cooper et al. [8], Béjar et al. [4], Cooper et al. [7] and Oliveira and Lisboa-Filho [9], allows the essential components of an SDI to be contemplated in the design phase, besides allowing for better understanding of the basic concepts, such as the structure of an SDI, who are its users and which roles they take on when using the SDI, how the policies impact the development of the SDI, etc.

The adapted ICA’s model proved adequate to describe SDI-Cemig. The differences found between the model and the specification are due to the specific characteristics of SDI-Cemig. During the specification of the actors in the Enterprise viewpoint of SDI-Cemig, the concentration of positions in the IT community becomes visible, which are responsible for providing data to SDI-Cemig, performing maintenance in smaller systems, negotiating new geospatial data and creating new policies. Many of these responsibilities are beyond the scope that IT should take on in SDI-Cemig. Ideally, administrative responsibilities and the responsibility of negotiating geospatial data would be attributed to other communities. Regarding the policies, the ones related to the type Governance have not been defined yet. Moreover, other types of policies have a small number of policies specified (usually a single policy has been specified for each type).

In addition, the impact the definition of actor roles on all viewpoints of an SDI can be seen. For example, the individual who takes on the Provider actor role influences the geospatial dataset available (specified in the Information viewpoint). In the Computation viewpoint, the actors are used as a reference to determine which interfaces are going to be effectively implemented in each of the SDI components. Furthermore, such interfaces are implemented following standards by the OGC. That allows an SDI, whether SDI-Cemig or any other that implements the same standards, to easily communicate with other SDIs at different levels. Thus, an SDI that has one individual for each actor role is more likely to have standardized components so as to facilitate the communication with other SDIs. Since the Computation viewpoint is impacted by the actors, the Engineering and Technology viewpoint are also affected.

The Information viewpoint of SDI-Cemig has all the components specified by the adapted ICA’s model, with no need to change their behavior or semantics. The specification of the Computation viewpoint in SDI-Cemig, however, has differences in the components specified by the ICA. The computational objects SDI Processing and SDI Management, at first, were not identified in SDI-Cemig, and their implementation is advisable to ensure that SDI-Cemig provides new functionalities to its users and to allow for greater control over the exchange of messages among components.

The Engineering viewpoint comprises structurally-isolated nodes, i.e., they work independently. Therefore, the failure of one component does not directly cause the failure of another. In the case a component is restructured, the other components do not need to be adapted since the communication is performed through channels, and the new structure only needs to use the same communication structure as the existing channels. As for components, the system may receive new functionalities with the creation of new objects and communication channels.

The Technology viewpoint is made up of technological objects representing them from physical components to functionalities that are organized independently and isolated among themselves. Their communication is performed through a service-oriented architecture, in which a technological object makes a request to another component using a communication interface in common. This way, replacing a component with a certain technology by another with a different technology does not significantly impact the SDI. The choices of technologies to create the technologies’ diagrams were based on the comparison of software described in the paper by Fonseca et al. [27] and on the company’s ease and familiarity in using them. The new functionalities in the project can be included by creating new components, as long as they have a communication interface in common and work in a service-oriented fashion.

A prototype of SDI-Cemig has been developed with all of its components implemented using only open-source software. Figure 13 shows a screenshot of the system.

6. Conclusions

This paper presented the use of ICA’s formal model, proposed based on the RM-ODP model, to specify a corporate SDI. The actor roles of the Enterprise viewpoint, originally proposed by Hjelmager et al. [6] and extended by Cooper et al. [8] and Béjar et al. [4], were unified due to inconsistencies in semantics and terminology. Such unification allows designers to use a common language when designing an SDI, thus facilitating the exchange of knowledge among themselves.

Although the use of ICA’s model to specify SDI-Cemig is not enough to validate the model for any corporate SDI, this study showed that the model is useful and appropriate to specify SDIs of that level. Moreover, the present study may help other designers wanting to use ICA’s model to specify new SDIs regardless of their level. Although the adapted ICA’s formal model describes the SDI at all levels and, thus, guarantees that the basic concepts in the literature are contemplated in the specification phase, there is no description of how the model should be used. For example, what is the level of detail required to describe the components of the Enterprise viewpoint? What could be considered a product specification in the Information viewpoint? How should the interfaces of components specified in the Computation viewpoint be compared with the interfaces of the SDI components?

The description of the Engineering and Technology viewpoints for SDI-Cemig suggests a specification to be used in other corporate SDIs, particularly in companies related to the power sector. Furthermore, the authors of this study believe SDIs of other levels (e.g., regional, national) that are not related to the power sector may use the specification of those viewpoints as the model. In case alterations are needed, such as replacing a technology, the model is made up of modules, which allow such change as long as the new technology meets the requirements described in the viewpoint. The use of independent modules allows new components to be added with no significant changes to the project in case new functionalities have to be added to the system.

As future works, it is important to apply ICA’s formal model to specify SDIs at others levels, such as at the local and state levels. Although there are initiatives for using ICA’s model to describe national SDIs [36,38], only the actor roles of the Enterprise viewpoint have been described. In other words, there are no studies describing the Enterprise viewpoint in full, besides the other viewpoints of ICA’s model and RM-ODP. In addition, the Engineering and Technology viewpoints can be generalized for specific technologies so as to facilitate other designers.