Social Media in the Process Automation Industry

Social Media in the Process Automation Industry Distributed Software Development Design Document Version 0.1 In co-operation with:

Title: Social Media in the Process Automation Industry Product name: ABBConnect Course: Distributed Software Development Document: Design Document Participants: Robert Gustavsson Dimitrios Kostopoulos Ditmar Parmeza Akhlaq Malik Pierfrancesco Ranieri Marta Milaković Mario Milas Tomislav Vresk Supervisor: Federico Ciccozzi Date: November 6th, 2013 2

Revision History Initials Action Date Version MMi Initial draft 26.10.2013 0.01 RG Added simulator to the skeleton and started on background 29.12.2013 0.02 RG MM,MMi MM DP RG DP RG MM, RG RG DK MMi, DP Added simulator design UML and a brief explanation. Also, High-level system design and arch. 01.11.2013 0.02 Added Scope, Added Software architecture 01.11.2013 0.03 Improved Software architecture 02.11.2013 0.04 Added GUI about web and mobile app 2.11.2013 0.05 Updated Simulator Design + added the GUI of the simulator 4.11.2013 0.06 Updated GUI about web and mobile app 4.11.2013 0.07 Added Common DAL and PL for both mobile and web 5.11.2013 0.08 Added BLL 5.11.2013 0.081 Updated all design diagrams 6.11.2013 0.082 Added sequence diagrams 6.11.2013 0.09 Proofreading revision, finalization for deadline 6.11.2013. 0.1 3

Contents 1 Introduction 6 1.1 Purpose of this document 6 1.2 Intended Audience 6 1.3 Scope 6 1.1 Technology definitions 6 1.4 Abbreviations 7 2 Background and objectives 8 2.1 Customer 8 2.2 Supervisor 8 2.3 Project vision 8 3 System overview 9 3.1 Description 9 3.2 System features 10 3.3 Integration 10 4 Software architecture 11 4.1 Conceptual design 11 4.1.1 Client - server architecture 11 4.1.2 Layered architecture 11 4.1.3 System architecture layers 11 4.2 Technologies used 13 5 Software design 14 5.1 Common Data Access Layer 14 5.2 Common Business Logic Layer 15 5.3 Web application design 16 5.4 Mobile application design 17 5.5 Simulator application design 18 5.6 Database model 19 6 Behavioral Design 20 6.1 Error handling 21 4

7 Graphical user interface 22 7.1 Web application 22 7.2 Mobile application 24 7.3 Simulator application 26 8 Addendum: Database Model 27 9 List of Tables 28 5

1.1 Purpose of this document 1 Introduction This document aims to give a detailed description on how the applications that will be implemented are designed. This is done by using high-level, component and more detailed class charts. The charts fill follow the UML-standards and will give a clear, structured overview of the system with the purpose of making the implementation more effective in the implementation phase. Furthermore, graphical user interfaces will be available for the front-end team. 1.2 Intended Audience This document is intended mainly for the development team but also for the customer and supervisor in order to ensure that they are satisfied with the application structures and that implemented features are fulfilling the customer s needs and requirements. Team members will use this document as a reference while implementing the application. 1.3 Scope The scope of this document is to give an insight into the design of the project Social Media in the Process Automation Industry. It provides details of the implementation design, system specification and architecture. Some low-level details will be described so that the understanding of the overall project will be easier while looking into details of some components and functionalities. This document is subject to change during the development process because of continuous increments on the functionalities. 1.1 Technology definitions ADO.NET ASP.NET Bootstrap Visual Studio Set of software components used for accessing data and data services based on DataSets and XML. Included in the Microsoft.NET Framework. Server-side web application framework by Microsoft. Framework used for creating websites and web applications. Contains HTML and CSS design templates, as well as JavaScript support. An integrated development environment from Microsoft. Table 1: Technology definitions 6

1.4 Abbreviations In this section, we provide short explanations for each of the abbreviations that have been used and mentioned in this document in order to make sure that every abbreviation used here will be properly understood by everyone who will read the document. ABB API BLL (Asea Brown Boveri) A multinational corporation with focus on robotics, power technology and automation Application Programming Interface Business Logic Layer C# Object-Oriented Programming Language developed by Microsoft DAL FER GUI MDH PM UI UML Data Access Layer Faculty of Electrical Engineering and Computing, University of Zagreb, Croatia Graphical User Interface Mälardalen University, Västerås, Sweden Project Manager User Interface Unified Modeling Language Table 2: Abbreviations 7

2.1 Customer The customers are Aneta Vulgarakis and Jonas Bronmark from ABB. Website: www.abb.com Contact: Aneta.Vulgarakis@se.abb.com 2.2 Supervisor Federico Ciccozzi, PhD - Mälardalen University Contact: Federico.Ciccozzi@mdh.se 2.3 Project vision 2 Background and objectives The project vision implies building a desktop and a device application that would practically have the features of social media for communication within the ABB staff. The purpose of building this application is to facilitate the communication between the small factory employees as much as possible - when it comes to stating different technical or professional issues in the company, reporting them to other colleagues, and trying to provide and agree on reasonable solutions. For a more detailed project vision, go to the project plan and vision document. 8

3.1 Description 3 System overview There will be three different applications that will communicate with each other through a common database. This system consists of a Web application for desktop use, a mobile application for device use and also a control application which handles sensor data. Figure 1 shows the high-level description of the domain, where the left side of the database is controlled by humans, and the right side is the control application, which is automated. It also demonstrates that the applications on the left side can both retrieve and send information to the database, while the control system can only send information. All the applications represented by the figure will be developed throughout this project. Figure 1: High-level design of the system Web application contains the same basic logic as the mobile application, but with upgraded features, and will be used on a personal computer. It will read all the needed data from the database, such as the feed, personal information etc. It will be developed using Visual Studio 2012, ASP.NET and Bootstrap API. Mobile application contains the basic business logic, shared with the web application, but with one special feature; taking a picture and uploading it to the feed. This application will be developed using Visual Studio 2012. The control application in this project will be a simulator of sensor data. This is due to the project team s lack of access to real sensors. The database will handle all data that is going through the system and will store it. Using one common database makes it simple for all applications to communicate and all the data is stored in one place. The database will be a Microsoft SQL database. 9

3.2 System features The desired functionalities for this application are focused around the social media-based way of reporting and tracking issues and work statuses within the work environment. The users, identified by their username and password, log in into the system and create a profile with their general information, which will be seen by other users. Consequently, users can follow feeds from other users. Feeds contain user and sensor posts. Posts consist of uploaded multimedia and/or text. After their creation, users can comment on individual posts. Posts can be grouped and filtered, and also traced to their source. Both mobile and desktop platforms shall have the access to the same information from one data subsystem (database). However, they do have some different intended features. The desktop application shall have the option of reviewing data and tasks from previous and current shifts, as well as alarming events that occur during the shifts. The mobile application shall have the support of capturing and uploading multimedia using the integrated camera and microphone. Additionally, an important aspect of the system is the feedback and visualization of data provided by sensors in the facility. They shall have the ability to post statuses and alarms in case their measures reach and cross preset critical values (thresholds). The data sent from the sensors should be stored, so a history can be later displayed in the form of graphs. 3.3 Integration The system consists of four subsystems: desktop and mobile applications, sensor simulator, and database. Since the desktop and mobile applications will share the same base business and data layer logic (same database), and a layered architecture will be used, it s important the model of the application is programmed according to interfaces. That way the integration process will be eased by the fact that the models need to be upgraded and/or implemented depending on the platform (Windows Phone or desktop), and linked to the presentation layer through interfaces. However, the control application will not have the same logic as the two described applications. Its model will be specifically designed for creating sensor data, which is then sent to the shared database through a special DAL. 10

4 Software architecture In the following paragraph the architecture of the application will be explained. The abstraction of the run-time elements of a system will be shown as a relationship between the modules, functionalities of each module, classes and its member functions, and interfaces of each of the modules that communicate together. The main focus here is how the major elements and components within an application are used by, or interact with, other major elements and components within the application. The software architecture of the application will be a layered architecture. 4.1 Conceptual design 4.1.1 Client - server architecture The user agent component will be a web based system using client-server architecture. The client can use either a mobile application or a web browser to connect to the service. On the server side, the web server receives requests from the client, handles them and sends an appropriate response to the client. Depending on the request, the web server then communicates with the database to load or save data. 4.1.2 Layered architecture As stated earlier, the system will have a layered architecture. The DAL implements the database connection classes for storing all the relevant data concerning the user and sensors. Presentation will provide a user friendly interface for communicating with the system. Most important functionalities will be implemented by the BLL. It has to control the flow of information and it has to allow instant sharing. 4.1.3 System architecture layers The system consists of three layers which can also be seen in Figure 2: Data Access Layer Business Logic Layer Presentation Layer This is done to improve the modularity of the application, and allow for easier extension of features, should one be needed. Dividing the logic allows the development team to program according to interfaces, thus allowing easier distribution of work. It should be noted that the simulator application will use a different model from the user applications. Specifically, the business logic layer will feature a range of different generators for sensors. The generated data will be used for later testing of the user agent applications. 11

Figure 2: Layered architecture Data Access Layer contains methods for accessing the underlying database data. These methods, when invoked, will connect to the database, issue the appropriate query, and return the results. The database and its stored procedures are included in this layer. Business Logic Layer serves as an intermediary for data exchange between the presentation layer and the data access layer. Business entities, or business objects, encapsulate the business logic and data necessary to represent real world elements. The goal of designing the business layer is to minimize the complexity by separating tasks into different areas of concern. Presentation Layer contains the components that implement and display the user interface and manage user interaction. To achieve maximum usability presentation layer for web application will be different from the presentation layer for mobile application. Web application will be developed using ASP.NET, and to build a connected mobile application that supports a wide variety of mobile devices, ASP.NET for Mobile will be used. 12

4.2 Technologies used Internal system logic, along with the simulator application logic, will be implemented in the programming language C#. Presentation layer of the web application will be developed using ASP.NET; and as for the mobile platform, ASP.NET for Mobile will be used. Additionally, the front end of the application will be written in HTML, JavaScript and CSS. The database used in this system will be Microsoft SQL Server. 13

5.1 Common Data Access Layer 5 Software design Diagram 1: Common data access layer class diagram The main feature (class) of the common DAL is the SQLProvider class. It serves as the main link with the database by maintaining a connection to it for storing and retrieving data. Moreover, it contains the basic logic which will be used by the clients (that are implemented by using C#) in the system. This includes sensors, feeds, comments and users. 14

5.2 Common Business Logic Layer Diagram 2: Common business logic layer class diagram The common BLL contains the factory classes, intended for updating and managing the attributes of specific feeds, sensors and users while enforcing the rules for those actions. This means that, for instance, assigning a user to a feed implies that an existing user must be added. Otherwise an exception will be thrown; or if a user selects an option to track a post, a post is added to his followed post lists on condition that it exists and has not been previously added. 15

5.3 Web application design Diagram 3: Web application class diagram The master page is the controller for the static content of a site i.e., the dashboard navigational elements. Depending on his selection, a method is called, and redirects the user to the selected page. The pages that are available for access are controlled by the following classes: MainPage - Used for updating and altering feeds, as well as refreshing feed status SavedFeedPage - Used for viewing a subscribed feed, and fetching post data from it ProfilePage - Overview and updating of user data SensorPage - Reading current from individual sensors and their data histories 16

5.4 Mobile application design Diagram 4: Mobile application class diagram Similar to the web application, the mobile application will be controlled by navigating through a menu, where the menu page contains the static elements for navigation. MenuPage - Controller for navigating through different pages, starting from the main page and page of saved feeds SavedFeedPage - Data display for the selected saved feed MainPage - Data display for the general feed overview, and also searching and commenting of feeds FeedPage - Comment display and refresh listener for individual feeds SensorPage - Data display for sensor data and history overview of previously measured data UserFeedPage - Display of feed data from an individual user, and linking to the user s profile page ProfilePage - Display and update of user data, also enabling calling or emailing by clicking that information. 17

5.5 Simulator application design The simulator application, also named Control System, will consist of three layers. Presentation Layer: Will contain four button events and one method. The initialization method will initialize the GUI and also fill it with the predefined sensors from the database. The events will be triggered when the user clicks buttons inside of the window. Business Logic Layer: Will consist of one class which handles the logics. It will contain all the sensors that are predefined in the database and will make it possible for the user to modify and add values of each sensor. Data Access Layer: Will make it possible for the BLL to make persistent change to the sensor values by inserting the new/updated values to the database. Diagram 5: Simulator class diagram 18

5.6 Database model The database model, located in the Addendum: Database Model of this document, has been designed according to the described features. The main entities in this model are the Feed, Users and Sensor. Every entity in the model is defined by an ID number which is referenced by other related entities. Users are defined by user data such as username, password, email, name and so on. They also have the option of following groups of feeds. Groups of feeds are stored in the FeedGroup entity. FeedGroups followed by a certain User are stored in the UserFollowedGroups relation. Each Feed is defined by the data, timestamp, visibility, tags, types of data posted (FeedDataType), and priorities (contained in FeedPriority entity, thus allowing custom priorities to be added). Users can add comments to a certain feed which are stored in the FeedComments relation. Each commenting activity is recorded as a FeedCommentActivity. Users can also follow feed publishers (UserFollowedFeedPublishers) that can actually be sensors and users. Publishers also have an Origin which implies the location from where they post. Sensors, besides being defined by names and ID number, also have the unit of measurement used and threshold for measurements that will be used for warning systems. Each Sensor produces SensorData that contain values of measurements which are performed by the sensor. Furthermore, the database will contain stored procedures that will be used as the communication between the tables and the applications. Some of those stored procedures are: GetUserInformation(userID : int) GetLatestFeeds() -- Return all new feeds + alarms GetHistoryValuesFromSensors(sensorID: int) GetUserFeeds(userID: int, from : DateTime, to : DateTime) GetUserInformation(userID : int) GetSensorData(sensorID : int) Login(userID : int, password : varchar) ChangeSensorBoundary(sensorID : int, ulimit : int, llimit: int) ChangeUserInformation(userID: int, name : varchar, address : varchar, email : varchar, phonenumber : varchar, location : varchar) InsertFeed(content : varchar, userid: int, location : varchar, tags : list<int>) InsertComment(content : varchar, userid : int, feedid: int) InsertSensorData(sensorID : int, value : int) 19

6 Behavioral Design In this section a portion of high important requirements will be presented as sequence diagrams. The first one is related to the authentication procedure followed in the mobile application. As displayed, the MU sends a request with his credentials to the responsible web service that communicates with the database. Those credentials are checked for validity and a response is sent back. Diagram 6: Authenticate smartphone Diagram 6 illustrates a high level interaction, when the mobile user accesses the system with his credentials. The web service will receive the request and will check the given credentials against the database. If the credentials are valid, the database returns a value. Diagram 7: Sensor data request 20

Diagram 7 illustrates a high level interaction, when the desktop user views the activity feed of a sensor. The sensor will request the web service for data, and the web service will retrieve the already generated data from the database. Diagram 8: Web application posting Diagram 8 illustrates a high level interaction that need to be completed, and results in a new post in a feed. The steps are simple: the DU initially creates a feed that contains the desired text or media file. Then the feed instance is stored in the database and an updated list of feeds is showed to the DU. 6.1 Error handling System errors will be handled by catching all the possible exceptions in the program and processing the ones related to the user actions. For example, if a user provides false or incorrect credentials for the login action, an exception shall be caught and displayed as a pop-up message. The message appearance and text may vary depending on the platform and the reason why the message is shown. 21

7 Graphical user interface In this section, we present a preliminary view of how the application will look like. As it was mentioned in the high level design, the application consists of four important parts: web application, mobile application, sensor simulator and database. The first three parts must have their own GUI (Graphical User Interface). Some mockups related to the web, application and simulator application are shown below. 7.1 Web application The preliminary view of the dashboard user interface is shown in the next figure. The user will have the possibility to viewing feeds according to the filtration made by his own choice. That means that the user can choose to either view both human and sensor feeds (mixed feeds) or just one of these. Filtering feeds according to feed priority should be also possible. The right side of the dashboard page is dedicated to feeds that are strongly related to the main user i.e., they can be feeds that have received many comments by the user. Figure 3: Dashboard UI Some alternatives of the Gauge Widget UI are shown below. They represent graphically the information that sensors publish in real-time. This facilitates the process in general since there is no need to have frequent published feeds from the sensors when they can report their status in real-time. 22

Figure 4: Gauge Widget UI Figure 5 gives a better view of the posts that are made by sensors. On the left side, the priority of the issue is specified. Then, a picture for identifying the sensor is provided. Finally, the description of the problem is given in the right side of the post. Figure 5: Sensor Feed UI 23

The way how priority posted issues are handled is shown in Figure 6. Two posts can be made simultaneously but the one with the highest priority will be ranked more on top of the page. 7.2 Mobile application Figure 6: Post priority in the UI Since the mobile platform offers a much smaller screen, and thus less space to accommodate the important elements, the main view will contain only the most important options and information related to the current page. The less used, navigational elements shall be located in the hidden swipe menu, opened by swiping the screen to the right. The mobile mockups are shown in the next six figures. Figure 7 presents a preliminary view of the profile page in the mobile application. Only basic information of the user is included in the profile page. The most important thing is that this information should be clickable and easy to access. For example, when the mobile user clicks on the email address, it should be possible to redirect him to the page where he can send an email to that address. Figure 8 shows a view of the menu in the mobile application. The menu should pop up when the user slides to the left. The structure should be as simple as possible. It will include the possibility for redirecting the user to the profile page, My feed page, Last shift page and Saved feed page. The mobile mockup related to the activity feeds is presented in Figure 9. The idea is that the outdoor employee should take a picture of a certain problem in the terrain and post it in the social media. Other users can comment in this feed and give feedback. 24

Figure 7: Profile Picture UI Figure 8: Menu UI Figure 9: Activity Feed UI Figure 10 shows how comments are displayed. Figure 11 and Figure 12 show the preliminary view of the saved feeds. Figure 12, it is possible to add a new query, for example a new shift of work. Figure 10: Comments Figure 11: Saved feeds Figure 12: New query 25

7.3 Simulator application The simulator GUI is simple and is not a high priority. Therefore, the standard Windows Forms colors and buttons will be used. When the application starts it will read the predefined sensors from the database and fill the listbox on the rightmost side with their names. If the user clicks on of these names the leftmost side will be filled it current boundaries. The user can then choose to change these and click apply to make that change also inside of the database. The user can also select a name of a sensor and click either Generate or Load to add values to the sensor. If Generate is clicked the simulator will generate values that are inside of the boundaries, but also some that are outside of it to trigger alarms. If the button Load is clicked the user gets the opportunity to choose a file, filled with sensor values, from his hard drive to load into the system. Finally, the user can click Publish Values and then all values that have been attached to the chosen sensors will be transmitted to the database every two seconds. Figure 13: Simulator s graphical user interface 26

8 Addendum: Database Model 27

9 List of Tables Table 1: Technology definitions... 6 Table 2: Abbreviations... 7 28