TU Wien - Technological Information Logging Tool

Transcription

1 System Specification of the Project TU Wien - Technological Information Logging Tool Dokumentname SystemSpecification_TILT_v1.docx Version 1.0 Datum Status First Version Lastenheft Projekt TU Wien - T.I.L.T

2 Table of Content Summary 3 Document History 3 Aims and Target Environment 4 Description of Current and Desired Situation 4 Current Situation 4 Initial Situation 4 Project Instigation 4 Desired Situation 5 Definition of Aims 5 Aims 5 Result 7 Usefulness 7 Product Use 7 Areas of Application 7 Target Groups 7 Product Overview 8 User Structure 8 Feature List 8 Use-Case Beschreibung zum Gesamtsystem 9 Product description 10 Product functionality 10 List of use cases 10 Graphical User Interface Layout 20 Weitere Funktionen Fehler! Textmarke nicht definiert. Schnittstellen 23 Product Data 24 Main Data 24 Further Data Fehler! Textmarke nicht definiert. Data Retention / Backups and Recovery 24 Produktleistungen und funktionale Randbedingungen 24 Quality Requirements 25 Product-Specific Requirements 26 Lastenheft Projekt TU Wien - T.I.L.T

3 Summary T.I.L.T. is a data storage and administration system for the institute for production engineering and laser technology at the technical university Vienna. The system shall help the scientists to store experimental measurement data as well as monitoring data in a standardized way. Currently, data is hardly stored at all. Several individual solutions are in place and working. Monitoring data is stored in a proprietary database with limited access. Therefore combination of data from different sources is impossible. This is not sustainable and limits the amount of knowledge generated from experiments. If successful, this project reduces the number of individual storage systems significantly and therefore makes the data accessible for the whole institute. The combination of measurements from different experiments as well as with monitoring data is expected to provide valuable insights. The system acceptance is critical. The system needs to provide a sensible benefit for the user in order to be adopted. 1. Document History Version Nr. Author Datum Changes, Reasons 0.1 Benjamin Mörzinger Julian Palmanshofer Document Creation Added following: Use case 001 Use case 002 Use case 003 Use case 004 Use case 005 Use case 006 Use case 007 Use case 008 Use case 009 Use case 010 Use case 011 Use case 012 Use case 013 Did some minor spell correction and translation Marcel Weilguni Overall Reworking Julian Palmanshofer Overall Reworking Felix Fasching Overall Reworking Juri Schreib Database 4.3 Database Lastenheft Projekt TU Wien - T.I.L.T

4 2. Aims and Target Environment 2.1. Description of Current and Desired Situation Current Situation At the institute for production engineering and laser technology several experiments are conducted. The results of those experiments are often measurements. Currently, no standardized form exists, in which these results are stored. Furthermore, different monitoring devices are installed. These devices measure different values constantly. For this group of measurements, a fundamental storage is already available. This solution however is based on proprietary software and cannot easily be adapted to the needs of research projects Initial Situation The Institute of Production Engineering and Laser Technology (IFT), department of the Vienna University of Technology, covers a wide area of production techniques and tooling machinery and is the scientific coordinator of the project. In development of processes for state of the art machinery engineering, the IFT is one of the most significant research centers for production engineering in Central Europe. The machining of advanced materials is one of the main research objectives at the IFT. Detailed research topics cover investigations of machine tool and process behavior as well as the interaction of cutting edge and part-materials. According to holistic approaches the process optimization issues also includes the analyses of the static and dynamic behavior of machine tools. Innovative production concepts could be performed in many R&D projects by application specific design of machine tool structures and control systems. A wide spread of manufacturing process applications for the biomedical and advanced mechanical industries have been developed regarding competitiveness in economic and ecological aspects. For the merger of economic and ecological aspects a working group was founded in Project Instigation By the end of 2016, the laboratory of IFT will be merged. Several modernization measures will be implemented throughout this process. One of these measures is the expansion of the existing monitoring infrastructure. Furthermore the whole IT-landscape will be changed which grants the opportunity to implement new features. Apart from the obvious benefits of the proposed system such as higher accessibility to measuring data and the resulting increase of knowledge generated from experiments, the project fits perfectly to the current questions in the production domain. Lastenheft Projekt TU Wien - T.I.L.T

5 Desired Situation A data storage system consisting of a database and the necessary software tool shall be implemented. This tool serve two main purposes: Store monitoring (online) data, so that they are accessible for research. Standardize the way experimental (offline) data is stored. The code should be adaptable for future use and a proper documentation is to be made. The stored data must be easily accessible for users. In order to be accepted by users, adding data to the database and data sources to the system must be as easy as possible. This will be done by the researchers. Users should have different rights and possibilities regarding adding, changing and retrieving (sensor) data depending on the person logged in at that time Definition of Aims Aims The result of this project is a database for measured data acquired at the newly built laboratory. Users will have to be able to add data sets and data sources easily. The goal is to implement a system that allows the client (TU Wien) to collect data from various sources, store the data in a standardized way and display the stored data via a website. These sources are machines and sensors which are used for scientific experiments and may vary in size, model, functionality and (most importantly) in output data. The tasks for this project are the implementation of a system that is able to standardize different types of data inputs (in order to allow the usage of various machines), store the standardized data into a secure database and implement a website that allows the user groups, according to their permission level, to view and edit stored data. In order to achieve this goal the product is split into a standardization software, a database and a website. In addition there needs to be a system connection layer in order to enable the communication between the above mentioned components. Seamless data retrieval for all authorized users must be ensured. A backup solution for those data-sets have to be implemented. Basic data visualization for both retrieved and experimental data to be uploaded must be in place. Lastenheft Projekt TU Wien - T.I.L.T

6 System Aims Standardization Layer Communicate with various hardware devices to gather sensor data Convert and filter the collected data so it can be computed more easily Data Access Layer Ensure that all parts of the project are capable of exchanging information in a reliable and efficient way Database and Data Integrity Create a database that can hold the gathered data for extended time periods Minimize the risk of data loss for the gathered data Graphical User Interface Implement Web Interface to interact with the gathered data (View, Edit, Modify, Delete) Manage User Access Modify, add and delete machines and sensors Documentation Create a detailed documentation that enables other developers to extend the project in the future Process Aims Depending on the resources left at the end of the project, one or more of the following process goal could be reached: Add additional support for multiple formats in the standardising layer Filter out empty data automatically Create a cloud backup solution that can save data indefinitely Test real world worst case scenario Optional Aims Algorithms for data aggregations within the database Implementation of data analysis algorithms Creation of Data Filtering System Advanced User Interface Compatibility Creation of Additional Features Lastenheft Projekt TU Wien - T.I.L.T

7 Non-Aims Cleanup services for saved data on the server Visualization of 3D models of data Backup data of the server data and the server software Printing of data, which exceeds the capabilities of the standard browser functionality Protection and availability of the IT infrastructure Export into other formats than CSV Continues management of experiments Function to comment by different users Socketlistener or other import channels Migration on Microsoft Windows or other distributions Hardware-Infrastructure Programming of microprocessors or any other low level devices directly connected to data gathering Result The result will be a software-tool for researchers at the IFT. The necessary hardware will be provided by the IFT Usefulness If successful, the system will increase the potential knowledge produced per experiment significantly. The possibility to access and combine data from several different data sources also lays the foundation for data related research topics and the buildup of a domain-specific knowledge base Product Use Areas of Application T.I.L.T is supposed to be used in an office environment. The main focus lies on supporting researchers in managing their experimental results and combining them with monitoring data. Areas of Application are project documentation, standardizing layer, website development and systems security as well as quality guarantee Target Groups The result of this project will be used by researchers at the TU Wien - IFT. The tool is supposed to help them to store and access data from experiments conducted in the past and monitoring data. Another target group are potential visitors and guests. The tool shall be capable of visualizing relevant data in order to give this group insights into the laboratory as well as the potential application of data related measures in a production environment. Lastenheft Projekt TU Wien - T.I.L.T

8 3. Product Overview 3.1. User Structure Admi Read- Only- Writer- User 3.2. Feature List Standardizing Layer Data conversion Sensor data is received in a specific format Data is converted in a database compatible format Data is saved into the database Standardizing Layer Management Configure custom conversion engines for standardizing Layer (Intermediate data storage (if the database server is busy or unreachable) ) Database Database modification User creates table for data storage User modifies table for data storage User deletes table for data storage User creates view for data retrieval Data Management Data is sent from standardizing layer to database Distribute data to multiple redundant databases to reduce the risk of data loss Move less used and old data to a long term storage solution or delete Data is read from the database Graphical User Interface (website) Admin Deletes data from database (any data set) Add sensor to measurement Remove sensor from measurement Allocate data-sets to a project/experiment User Imports data from a valid JSON file Allocate data-sets to a project/experiment Views existing measurement data from a specific measurement type during a specific time period via diagrams Lastenheft Projekt TU Wien - T.I.L.T

9 3.3. Use-Case Beschreibung zum Gesamtsystem Lastenheft Projekt TU Wien - T.I.L.T

10 4. Product description 4.1. Product functionality List of use cases Use Case 001 Name Short description User login This use case describes the way in which a user can login into the graphical user interface in order to have access to certain functions Agent User Graphical User Interface Trigger Result Pre-condition Data input Post-condition Process description Error handling Variations Once the user has pressed the Login button, the process will start. The user will be logged in either as read-only user, write user or as admin A valid password was entered User password The entered password has to be valid The Login button is pressed by the user The entered password is checked for validity The next use case (Use Case 002) will be triggered An error message will be shown on the graphical user interface There are three valid passwords, each granting access to a different user with different permission levels Lastenheft Projekt TU Wien - T.I.L.T

11 Use Case 002 Name Short description Name of the user This use case describes the way in which a logged in user enters his name. Agent User Graphical User Interface Database Trigger Use Case 001 Result Pre-condition Data input Post-condition Process description Error handling The logged in user will get a name of the actual person using the account. This is logged in the database A name was entered Name of the actual person The name must not be empty Use Case 001 calls Use Case 002 The user enters his name The entered name is checked for validity The name will be logged in the database An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

12 Use Case 003 Name Short description Assign data to an experiment This use case describes the way in which a logged in user assigns certain data to a specific experiment Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly Certain data is assigned to a specific experiment The user is logged in Time period, machine and experiment The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user selects a time period, machine and experiment The selected data will be assigned to the selected experiment in the database An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

13 Use Case 004 Name Short description Displaying stored data This use case describes the way in which a logged in user displays stored experiment or sensor data Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly Certain data is displayed via the graphical user interface The user is logged in Time period, machine and experiment or sensor The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user selects a time period, machine and experiment or sensor The selected data will be displayed via the graphical user interface An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

14 Use Case 005 Name Short description Exporting stored data This use case describes the way in which a logged in user exports stored data Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly Certain data is exported as CSV file The user is logged in Time period, machine and experiment or sensor The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user selects a time period, machine and experiment or sensor The selected data will be exported as a CSV file An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

15 Use Case 006 Name Short description Reading logfiles This use case describes the way in which a logged in user accesses a logfile Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly A specific logfile is displayed The user is logged in Specific logfile The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user selects the wanted logfile The select logfile will be displayed on the graphical user interface An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

16 Use Case 007 Name Short description Creating a sensor This use case describes the way in which a logged in user (write user or admin user) creates a sensor Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly A sensor with certain attributes is created The user is logged in as either a write user or as an admin Sensor attributes The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user enters the sensor attributes The sensor will be created An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

17 Use Case 008 Name Short description Importing data This use case describes the way in which a logged in user (write user or admin user) imports data Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly Input data is stored in the database The user is logged in as either a write user or as an admin Input file The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user uploads the file The file will be checked for validity The input data is stored in the database An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

18 Use Case 009 Name Short description Adding sensor attributes This use case describes the way in which a logged in user (write user or admin user) adds an attribute to an existing sensor Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly An attribute of an existing sensor is added The user is logged in as either a write user or as an admin Attribute, which shall be added to the existing sensor The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user enters the new attribute and the target sensor The attribute will be added to the sensor An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

19 Use Case 010 Name Short description Changing user passwords This use case describes the way in which a logged in admin user changes an existing user password Agent User Graphical User Interface Database Trigger Result Pre-condition Data input Post-condition Process description Error handling User interacts with the graphical user interface accordingly The password of a certain user is changed The user is logged in as an admin user New password The input data has to be valid and must not be empty User interacts with the graphical user interface accordingly The user enters the new password and selects the user whose password shall be changed The password of the selected user will be changed An error message will be shown on the graphical user interface Lastenheft Projekt TU Wien - T.I.L.T

20 Graphical User Interface Layout Lastenheft Projekt TU Wien - T.I.L.T

21 Lastenheft Projekt TU Wien - T.I.L.T

22 Lastenheft Projekt TU Wien - T.I.L.T

23 Schnittstellen User- Software: User inserts new data source (measurement device): Every authorised user can add new measurement devices. In this process he or she defines the data format and how the data needs to be stored. The person who created the entry for the measurement devices is the administrator for the respective device. Once defined measurement devices can be connected to machines. Furthermore, those devices can be used as the starting point for the instantiation of other, similar measurement devices (device library). For online (monitoring devices), this is the moment, data is written to the database. Other data sources (experiments), users add data manually. User adds experiment-data: For every experimental run, the user can decide to write the measured values to the database. This has to be done manually. The software needs to be designed in a way, so that the users accept the system features (i.e. uploading the data needs to be easier than the current solutions (csv+excel ). User reads data: For any given period of time, any given dataset can be retrieved. Datasets are defined by the measurement device used and the machine the measuring device was installed at. This feature must only be accessible for IFT-scientists. For visualisation purposes or guests, limited access to the read data is necessary. User-Database: The administrator needs to be able to manually manipulate the database. Software-Database: Data is written to database Data in database is filtered (Rauschdaten) Lastenheft Projekt TU Wien - T.I.L.T

24 4.2. Product Data Main Data Offline Data: Not connected with the monitoring system. Are provided manually by users in the form of.csv-files. Online Data: Data is transmitted via TCP/IP at an adjustable rate. Data sources are in the same VLAN as the Server. The connection is established by the measurement device. For both data sources the following datatypes might be provided: Boolean Integer (32bit signed) Float (32bit) DateTime (milli-second range) String (variable length, UTF-8 coded) Performance estimations: 50 send per second: 1 DateTime 4 Float 4 Integer 1 String (80 symbols) The resulting data should be stored for approximately 2 years Data Retention / Backups and Recovery The database is the final non-volatile storage for all Information fed in the System. It acts as an archive, the application has to access it, to fetch data and present it to the user. To ensure that the data integrity is guaranteed, all data is stored redundantly in multiple physical locations. General Requirements Collect Data at a rate of entries per second (10 entries/ms) Ignore invalid or corrupt data Backup Requirements Store Data redundantly in multiple physical locations Regular Backups to minimize the risk of data loss Database Product Requirements Relational Database SQL compatible Open Source Consistency and Availability 4.3. Produktleistungen und funktionale Randbedingungen Standardization Layer /SL01/ A sensor may not write measurement data faster than once every 10 milliseconds. Lastenheft Projekt TU Wien - T.I.L.T

25 /SL02/ Measurement data has to be directly written into a document /SL03/ Every Sensor writes into an individual document /SL04/ The naming convention of such documents shall be SensorID_SEQUENCERID.json (Sequencer is an increasing numerization) /SL05/ For the Sequencer a 16 bit value should be used (more not necessary since there cannot be more than files in queue at one time by one sensor) /SL06/... /SL06/ While writing measurement data, the document must not be closed /SL07/ There may only be a 10 seconds delay of the measurement interval (A sensor with a measurement interval of 1 second may only write 10 measurement values, a sensor with a measurement interval of 10 milliseconds may write 1000 measurement values) /SL08/ The number of measurement values has to be chosen in a way, that there is at least a time difference of 1 second between the creation of files /SL09/ The parser will use prepared statements after checking the file /SL10/ The parser might stop reading a document if there has been no CLOSE_WRITE for more than 1 hour -> the sensor should be programed to automatically stop after 1 hour Database & Backups /DB01/ Permanently store all valid information fed into the system /DB02/ Ensure the information is accessible by the application using SQL Queries /DB03/ Withstand up to entries per second (10 entries/ms) /DB04/ Insert new data into the database using SQL queries /DB05/ Database views are provided to display information /DB06/ The Database will provide documented users and passwords to execute queries on the Database /DB10/ Minimize the risk of data loss by storing all information redundantly /DB11/ If not enough disk space is available to store incoming data, the oldest sets will automatically be removed /DB12/ If the required hardware requirements for data integrity are not met, the administrators will be informed 4.4. Quality Requirements General Requirements Excuselefly use open source technologies Document all units and integrations Lastenheft Projekt TU Wien - T.I.L.T

26 Product-Specific Requirements Anforderungen an die Produktqualität Quality Requirement Notes, Comments Functionality Normal Tool will be used on a constant basis. Reliability High Reliability is crucial for user acceptance Continuous Operation High Especially Monitoring data will be fed into the database constantly. Experimental data or data sources can be added at any time. Usability High Researchers need to be able to store and access data easily. This is crucial for user acceptance. Accessibility Normal Access via IFT-Network needs to be provided. Efficiency Low Data rates are expected to be low enough for a normal PC system to easily be able to cope with the resulting processes. Adaptability Very High T.I.L.T will be used under constantly changing conditions. Data sources will be added and changed. Transferability and Portability Low T.I.L.T is designed to be applied only at the IFT Correctness Very High Experimental data often can only be produced under very specific conditions and the process is always time consuming. Data must be reliable. Robustness Very High Experimental data often can only be produced under very specific conditions and the process is always time consuming. Data storage must be reliable. Extendability, Maintainability Very high This system is expected to lay the foundation for further research in the area of data science. Maintenance will be done by researchers. Therefore the necessary actions must be realistic to be carried out by untrained mechanical engineers with intermediate IT-knowledge. Reusability Low Is not intended. Compatibility Low T.I.L.T only needs to function on Windows PCs Lastenheft Projekt TU Wien - T.I.L.T