HUMAN SAFETY MANAGEMENT PROCEDURES
Introduction
Explain what is the component about and its architecture with a small architecture diagram.
In the followng figure is represented the high level Architecture for Food & Beverage – filtration powder use case. The architecture is composed by 3 main layers. A Field Layer that contains sensors, cameras and alarm device to inform the operator of an hazard. From this level video flows and sensors data are sended to the On-Edge Layer. In this level a computer vision module implements Machine Learning models running on-board on computational units to search for entities, like operators, in the working space. A Hazard Orchestrator evaluates if a hazard event, like a collision, is possible. If the event is happening the Orchestrator sends an alarm to the operator and stop command to the involved machines (cobots or forklift). Simultaneously it sends events data to the upper layer, through a set of Rest API. In the Cloud Layer the backend module stores the event and update the KPIs. Also it instantly shows the event on the map of the monitored area.
Technical Specifications
Software and hardware Requirements
Software
The Amazon Web Services are the most used SW services in the system. A container infrastructure is adopted to manage the deploy of the platform. The most used AWS service is Greengrass. that provides ML processing, messaging, management, synchronization, and inference capabilities for securely connected devices. With AWS IoT Greengrass, connected devices can run AWS Lambda functions, Docker containers, or both, make predictions based on machine learning models, keep device data in sync, and communicate securely with other devices, even when not connected to the internet. AWS IoT Greengrass seamlessly extends AWS to devices so that they can act locally on the data they generate, while continuing to use the cloud for management, analytics and durable storage. With AWS IoT Greengrass, you can use familiar programming languages and templates to build your device software in the cloud and then distribute it to devices. AWS Iot Greengrass can be programmed to filter device data and transmit only the information you need to the cloud. The relational database POSTGRES has been used to implement all the tables to store the data coming from the system and the data that we need to let the system work properly (users, workers and groups data). DynamoDB is what we use to manage the data throughput between the cloud and the lower layer of the applicaton. It provides the elimination of old files and the backup of the new tables. It also secure the performance for every workload. The implementation is dedicated to the Athenian Brewery - Filtration Powder use case. To implement the collisions detection many components have been used. On the edge we use stereo-cameras to get the video, the dockers and AWS greengrass core as edge module.
Hardware
- Stereo Cameras: Stereo Labs ZED 2
- Edge Computing Unit: NVIDIA Jetson Xavier
- Internet Connection: LTE provided by 4G SIM or ethernet connection
Usage Manual
In this section the main features of the component should be identified and explained.
It also should include the explanation step by step each of the identified use cases.
Use Case 1.
Use Case Diagram
Explain with text, images, and mock-ups how the user will interact with the component to achieve their goal in that specific use case.
The following is the use case diagram for the Foods & Beverage use case, particularly the macro-case of the filtration powder, that is the one on which the human-safety system is implemented. The system developer has the task of identifying critical issues in the plants together with the HSE Manager and defining the use cases to be implemented to improve safety. Once the use cases have been defined, the necessary information is collected in the plant to apply the use cases, if the information is not present, the installation of dedicated HW is required (cameras, stereoscopics cameras, beacons, other sensors). All information must be submitted to the Safety Management Platform. The application developer has the task of configuring the rules to be applied based on the information received. The HSE Manager will have to identify the corrective procedure that the workers will have to implement for each safety violation detected. Workers must apply the procedures defined by the HSE in terms of Safety, in case of violations detected by the system they must apply corrective actions. The computation unit is wired with the on field cameras, stereo-cameras for the forklift and on-edge cameras for the cobot. The CU verifies that the position of the operator is in the safety area. When an operator becomes an obstacle, entering in the working space of the cobot or the forklift, the computational unit sends a stop signal to both the cobot and the forklift. Also, it sends an alarm to the system so that it can store the hazard event. The forklift and the cobot immediately stop working when they receive the stop signal. The user is alerted from the alarm device present on field and can start to adopt the HSE procedure. After the hazard events are stored on the system the HSE manager can visualize the actual event and all the history on the platform.
Use Case Mock-ups
Mock-ups are needed in the applications (for the mock-ups use the templates prepared in Figma).
The human safety platform displays the alarms in real-time, as shown in Figure 26, in the console and it generates alarms on the plant to alert workers (e.g. light and acoustic signals).
The platform implements a user and workers management through a dedicated functionalities and interfaces. The administrator, like a HSE Manager, can register new user assign roles, permissions and group. Furthermore, the admin user can register plant workers. In this case the platform and the entire system keeps the anonymity of registered operators, compliant to the GDPR legislation.
The platform provides dashboards composed by elementary graphic widget to monitor all alarm events detected in the selected period. It is also possible view and export the list of all recorded events.
Functional Specifications
Functional Block Diagram
Functional diagram showing the interrelationships between the functional (sub-)components. Explanation.
Following are described function diagrams related to foods & beverage use case. For this use case the functional diagram of the safety platform shows that the platform needs to be feed with some information. First is working area parameters, which define the monitored areas. Second one is the collision threshold, that is the minimum distance between two entities, like forklift-operator or cobot-operator. When these parameters are configured the system is listening for hazard events. If an alarm is sent from the field the platform registers, shows the event and update the events history.
In the following diagram are shown the following Safety Platform functionalities: add/delete users, workers, groups, assign roles, show actual events, events history and hazard KPIs. All these functionalities are generic and valid for all the use cases of the project.
From field side, some ambient data are collected from cameras and sensors. Through entities recognition modules and location computation is possible to determine if some operators are present in the working area. In this case the position of the operators is compared with the one of the cobot and/or the forklift. If the distance between them is less then the collision threshold configured on the platform by the HSE administrator, then, simultaneously, a stop command is sent to the cobot/forklit, an alarm is sent to the operator device to inform him about the danger and the event info are sent to the platform to store data.
Main interfaces
List of main interfaces between functional components shown in the figure.
| ID | Component | Name | Description | Sense |
|---|---|---|---|---|
| 1 | Functional sub-component 1 | Name 1 | Description 1 | In |
Sequence Maps
Sequence maps showing the interactions between the functional (sub-)components. Explanation of flows.
In the login sequence diagram the user submit its credential, verified by Identity Manager module. If the user is registered in the user DB, the IDM send the access token to the FE, showing the successfull login page to the user. Otherwise the FE will display the user's login page with the reasons for denied access.
The add user process starts with the insertion, by the admin of the platform, of the user info. Personal info like name and surname, user info like password and role, and contact info like email or phone number. Notice that the registered users are the ones who will access to the platform and not the field operators. Then Backend collects all the info and sends query to the User Database. If the query is correct, user is registered on the Database so ACK is sent to the Backend module and user is addressed on the successfully registered user page. Otherwise Database sends to Backend the NACK message to the Backend and user see on the registration page the specific error, for example missing fields, uncorrect fields, or system errors.
The procedure to register a worker is similar to the one to register a user. The only difference is in the registered information. The personal info of a Worker that ca be used to personally identify him are not registered on the system in order to respect the GDPR compliance and privacy legislation.
The procedure to register a group is similar to the one to register a user. The difference is the info associated to a group. These info are group name and permissions. With the latter is possible to associate which resources (users, workers, group, roles) can be managed by the group.
The logged user select the user to be deleted from the user list page. Request is sent to the Backend that query the DB. If the query succeed user is redirect on the users list page with successfull message, otherwise the same page is shown with error page. The same behaviour is applied for the workers and groups deletion.
When real time events map is requested the Frontend sends to Backend the request. Query is turned to Database. If live hazard events are present the response is positive and the events list, attached with events positions, is sent to Frontend on map through Backend. If live hazard events are not present or an error occurs Frontend shows only an empty map of the plant. The events hystory page and KPIs page is retrieved in the same way. The KPIs are configured when platform is installed, from the administrator of the system. Every time a new hazard event occurs the Backend updates the configured KPIs in real time.
