Status:

completed 01/2022

Aims:

The project was initiated by the Exposure and Risk Assessment department of the Institute for Occupational Safety and Health of the German Social Accident Insurance (IFA) for the initial trial of new software development, documentation and quality assurance standards as well as project organisation and management standards and primarily serves the qualification of internal resources. In particular, the focus was the trial of an iterative approach as well as the development of the application as a progressive web app. This application will be freely available on the internet. The object of the development was the evaluation of the incentive to defeat protective devices on machinery. Workplace safety experts estimate in a survey that around one third of all protective devices on metal processing machines are bypassed, because the protective devices make working on the machines in question more difficult. The machines concerned have a significantly increased risk potential and rate of accidents. It has been proven that the defeating of protective devices has already led to fatal accidents. As such, it must be ensured that the protective devices do not make work processes more difficult, thereby eliminating the incentive of defeating and bypassing the protective devices. The aim of the system to be developed was to document protective devices and evaluate the incentive for defeating using recorded data. The application uses a process developed by the Institute for Occupational Safety and Health of the German Social Accident Insurance (IFA) to evaluate incentives for defeating on stationary machines. Defeating may occur, for instance, on safety doors, barriers, machine guards, etc.

The application is aimed at manufacturers, plant owners and those familiar with the machine (service technicians, employees, etc.).

Activities/Methods:

The architecture of the software corresponds to that of a modern web application and comprises an Angular front-end framework, a Spring back-end framework, an Oracle database and an OAuth 2.0 authentication provider. The communication between front end and back end takes place via a JSON-based REST interface. For the communication with existing components, JSON or XML should be used.

The four-tier architecture approach was used. Each of these tiers has specific duties. To build a clean structure, components of a higher tier can only use components of the same tier or the tier immediately below it.

The following tiers are defined:

1. Client: User interface of the system, i.e. front-end dialogues. This also includes any peripheral systems (such as adoption assistants or other fat clients) or smartphone clients.
2. Service: Publishes the functionality of the system externally for clients, batches or neighbouring systems; façade pattern which is usually also home to central transaction and fault handling.
3. Business logic: The actual business logic with which the applications of the specification are implemented.
4. Data access: Encapsulates the read and write access to data from the database (persistence). Technical cross-section server components cannot be assigned to any of these tiers and are in principle available in the three tiers service, logic and data access.
5. Based on the respective development cycles, the software will undergo several intensive tests in line with usual market methods and standards, carried out both internally and by experts of the application domain.

Results:

The system developed enables the documentation of protective devices and the evaluation of the incentive for defeating using recorded data.

In the scope of the project, not only the initial requirements were able to be implemented, but also necessary changes and additions that came up in the further course of the project. Technical and functional tests were successfully performed, documented and passed.

The specialist department has decided to implement further additions to the application using its own resources. The source code as well as the project documents are available for this purpose and must be expanded and updated according to the additions/changes.

The final Corporate Design approval will only be sought after the upcoming changes, as this makes most sense.

Last Update: