safety system modularity

32
WP3: PSS Modularity General Overview for First Milestone and Upcoming Activities CERN-EDUSAFE Meeting 28/10/13

Upload: fasiul-alam

Post on 11-Apr-2017

164 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: Safety System Modularity

WP3: PSS Modularity

General Overview for First Milestoneand

Upcoming Activities

CERN-EDUSAFE Meeting 28/10/13

Page 2: Safety System Modularity

Overview

CERN-EDUSAFE Meeting 28/10/13

• CS and DAQ System

• DAQ Modular software

• DAQ Server software

• Integration Process

• Risk points

• Delay or other issues

• Questions and Comments?

• WP3 Outlines

• Scheduling-Milestones

• Work Methodology

• Analyses

• Use Cases

• Design concept for Modular

Architecture

Page 3: Safety System Modularity

WP3 Overview

CERN-EDUSAFE Meeting 28/10/13

WP3 focuses on studying the scalability and adaptability potential of the hardware and the software of the PSS module, the Control System (CS) and the Data Acquisition system (DAQ) for other markets and different types of environment. Focus is also on the safety system modularity and integration aspects.

It is divided into two parts.

1. This individual research project focuses on design and integration optimization of the PSS module which hosts the communication module, the safety sensors and the local intelligence for data/video local treatment. It is an essential node for propagating the data from the cameras and sensors to the control system and vice versa from the control system to the HMDs. It is a key element to the success of the project. Additionally, a very challenging optimization is required at all design levels (electronics miniaturization, power consumption, integration, interfaces, wireless HW) to produce a system sufficiently powerful, highly reliable, with small size and weight, suitable to the workers in the most demanding environments.

2. The CS and DAQ architecture and components hierarchy need to be designed and integrated to meet the stringent requirements from the AR technology and the software implementation constraints. It needs to be adaptable and scalable to various working environment (sea, space, large underground areas,..) and must easily accept various types of detectors/sensors. Attention needs to be paid to maintain high speed communication rates and data exchange between the supervised persons and supervisors. The control system will be developed through web-based methods, the data registered to a proper data-base for easy access for off-line analysis, the calculated environmental radiation activation maps compared and agree with the radiation data measured on the field. The preparation of radiation maps is an essential activity and must be solid and well understood.

Page 4: Safety System Modularity

WP3 OUTLINES: Deliverables and Milestones

CERN-EDUSAFE Meeting 28/10/13

DeliverablesD. No. Deliverable name Month of delivery (Project

months)3.1 Control and DAQ system HW and SW architecture design report, PSS module HW and SW

architectureM16

3.2 Annual appraisal of research progress and training M18, 30, 423.3 PSS module, CS, DAQ first prototype developed, performance test and system documentation M32

3.4 PSS module, CS, DAQ 2nd prototype developed, performance test and system documentation M40

3.5 PSS system module, CS, DAQ HW+ SW final doc. incl. final tests results and recommendations, and incl. report on scalability and adaptability to different infrastructure and environmental conditions

M42

3.6 Presentation of Fellow’s research at end conference M48

MilestonesM. No. Milestone name Month of Milestone

(Project months)19 PSS module design, CS and DAQ system architecture design M1620 PSS module first prototype manufactured, Control system and DAQ first prototype developed

M30

21 PSS module final prototype developed M3622 Local specific trainings completed M42

Page 5: Safety System Modularity

Work Methodology

CERN-EDUSAFE Meeting 28/10/13

Page 6: Safety System Modularity

Qualitative and Quantitative Analyses

CERN-EDUSAFE Meeting 28/10/13

A hazard analysis, predesign or postdesign, can be designated as qualitative or quantitative. A qualitative analysis is a nonmathematical review of all factors affecting the safety of a product, system, operation, or person. It involves examination of the actual design against a predetermined set of acceptability parameters. All possible conditions and events and their consequences are considered to determine whether they could cause or contribute to injury or damage. A quantitative analysis is a mathematical measure of how well energy is controlled.

A qualitative hazards analyses are conducted in the following sequence:1. Identify both design and operational primary hazards (i.e., sources of danger) that could generate injury, damage, loss of function. These constitute the top-level events. All other factors contribute to or affect these top-level items.

2. Identify factors contributing to the top-level events. These are listed as they come to mind. The analyst lists everything that could have an adverse effect on the product or system. The list can be developed from theoretical considerations of possible hazards, from results of past failures of equipment, or from knowledge of problems with similar systems or subsystems.

3. Items on the preliminary list are rearranged according to the effects that they will produce. Generally, this rearrangement is done by continuing the analysis down through additional cause and effect levels. In some instances, certain conditions or events may be included in more than one area.

4. Any other events, which consideration indicates should be included are then added to the analysis.

5. Determine what action most practically will control the triggering mechanism considering time sequencing, severity, frequency, etc.

Page 7: Safety System Modularity

Qualitative and Quantitative Analyses

CERN-EDUSAFE Meeting 28/10/13

Quantitative Analyses: This type of analysis is a determination of how well hazards are controlled in a system, subsystem, or event. In any case, quantitative safety analysis must be based on a qualitative analysis. Numerical values are then applied. A probability analysis may be accomplished in a number of ways depending on the desired end result.

1. Probabilities may be derived from experience data on operations of similar systems, preliminary tests, synthesized combination values, or extensions of all of these. The quantitative expression may include not only the expected rate at which the hazard will cause accidents but also the severity of damage that could result, or it may include both.

2. It is morally and legally unjustifiable to permit a hazard to exist unless appropriate effort is applied to eliminate it, control it, or limit any damage that it possibly could produce.

3. Sometimes, data are valid only in special circumstances. Generalized probabilities will not serve well for specific, localized areas.

4. Reliability is the probability of successful accomplishment of a mission within prescribed parameters over a specific period of time.

5. Design deficiencies are rarely quantifiable and can be easily overlooked by a quantitative analysis.

Page 8: Safety System Modularity

PSS Major Use Cases

CERN-EDUSAFE Meeting 28/10/13

Page 9: Safety System Modularity

PSS Other Use Cases

CERN-EDUSAFE Meeting 28/10/13

Industrial Safety/Operational Safety/Biomedical Safety• Compliance with federal, state, and local industrial codes and regulations.• Required state inspections of equipment, such as boilers, cranes, elevators,

degreasers, fire systems, etc.• Fire prevention and control program.• Personnel accident prevention program and statistical records.• Temperature and humidity control.• Noise level control within the plant.• Personal protective clothing requirements, i.e. safety glasses/shoes, hard hats, non

static work clothes, etc.• Safe and adequate tools for the job to be done.• Safety guards for moving parts of machinery, such as pulleys, gears, saws, grinders,

conveyors, etc.• Material handling and storage methods.• In-plant cleanliness and good housekeeping practices.• Motor vehicle safety program.• Adequate lighting for type of work.• Warning alarms and signs.• Employee safety training.• Personal hygiene and first aid programs.• Proof testing and identification of lifting sling, ropes, etc.• Security control of identified hazardous areas.• Guard rails on platforms, stairs, walkways.• Personnel protection during hazardous testing.

Page 10: Safety System Modularity

CERN Use Cases

CERN-EDUSAFE Meeting 28/10/13

Actors : Actions Technicians :

Technician is the user that will carry the module and the helmet with the camera/ glass or the handheld camera and devices.1. Set on/off the device.2. The battery level3. The overcoming of a parameters4. The operational status5. Communicate with the supervisor 6. Send a panic or emergency signal7. Control the leds on the helmet for lighting8. Adjust the sound volume

Supervisors :Supervisor will receives all the latest measurements in real time and will communicate through audio/video and camera with the technician.1. Air humidity and temperature2. Body temperature3. Oxygen4. Carbon Dioxide5. Radiation6. Heart beat rate7. Acceleration for fall detection8. Communicate with the technician9. Get the image from the helmet or handheld camera10. Status of the module11. Emergency signal

Admins :Administrator will have rights to change parameters and maintenance the modules and the server side programs like the DAQ.1. Register to the system the users and the devices.2. Assign a module to a User through the DAQ application3. Set the module operational parameters

1. The WiFi parameters like SSID, security, static IP or domain etc.2. The up and down limits of the measurements3. Sampling rate

4. Set the transmition period5. Get all the stored data for further analysis

Supporters :Support User will have access to get the system’s data through third party applications for further analysis.

Page 11: Safety System Modularity

Design Steps: Grouping

CERN-EDUSAFE Meeting 28/10/13

Page 12: Safety System Modularity

Design Steps: Group outlines

CERN-EDUSAFE Meeting 28/10/13

Page 13: Safety System Modularity

Design Steps: Inside of Processing Group

CERN-EDUSAFE Meeting 28/10/13

• Low power Microcontroller/ Processor Some of the features will be System-on-Chip, 16/32-bit, channel correlator and an on-board Flash memory, extra CPU computing power and a wide range of hosted peripherals – CAN, SPI, UART, I2C, USB and others, with external memory interface allowing glueless connection to external devices including a Zigbee/Acoustic/RFID/ GSM/GPRS module, smartcard and DSP and text-to-speech, data short range communication, radio controller and mobile computing platforms – PDA and smartphone.

• Gumstix Interface/DSP Processor

Gumstix / DSP processor will collaborate with design. It will go from concept to finished design in development times. It will be equipped with camera control signals or a wide range of expandability options.

Page 14: Safety System Modularity

Design Steps: Inside of Sensing Group

CERN-EDUSAFE Meeting 28/10/13

Gas sensor block: Will contain different gas sensors like O2, CO2, CO, H2S etc

Environmental Condition Monitoring block : Will contain Accelerometer , fire

sensor, shock, ultrasonic , optical/light, infrared, humidity sensors etc.

Human Sensing Block: Will contain heartbeat /ECG sensor, body temperature

sensor, etc.

Location awareness Block: Worker situation and position

Page 15: Safety System Modularity

Design Steps: Inside of Interfacing Group

CERN-EDUSAFE Meeting 28/10/13

Zigbee block: Will contain different radiation sensors

GUI: A GUI will be connected for user interface

RFID, USB and wireless ports for different interface options

Location awareness Block: Worker situation and position

Page 16: Safety System Modularity

Design Steps: Inside of Communication Group

CERN-EDUSAFE Meeting 28/10/13

Wi-Fi MODULE

RFID/ Bluetooth

Optical network

GSM

Acoustic

Page 17: Safety System Modularity

Design Steps: Inside of Power Group

CERN-EDUSAFE Meeting 28/10/13

• Rechargeable Li-I battery

• Photovoltaic cells

• Micro power device

• Thermoelectric power etc.

Page 18: Safety System Modularity

Design Steps: Integration process

CERN-EDUSAFE Meeting 27/10/13

Page 19: Safety System Modularity

Design Steps: Integration process

CERN-EDUSAFE Meeting 28/10/13

Page 20: Safety System Modularity

Design steps: Groups are connected through M/F sockets

CERN-EDUSAFE Meeting 28/10/13

Finally it will be formed like as a

sandwich!

Page 21: Safety System Modularity

Blocks of PSS system in General

CERN-EDUSAFE Meeting 28/10/13

Page 22: Safety System Modularity

Block Outlines of NEW PTU

CERN-EDUSAFE Meeting 28/10/13

Page 23: Safety System Modularity

HW/SW Outlines of New PTU

CERN-EDUSAFE Meeting 28/10/13

RTX

Ope

ratin

g Sy

stem

Application

Devices Drivers

Peripherals Drivers

Hardware

DAQ Script Manager

Page 24: Safety System Modularity

CS and DAQ System

CERN-EDUSAFE Meeting 28/10/13

•General Overview of PSS Module

• Work Methodology

• Objectives of Modular system

• Use Cases

• Modular Architecture

• Integration Process

•Software - DAQ System

• DAQ Modular software

• DAQ Server software

• DataBase

•Scheduling - Milestones

Page 25: Safety System Modularity

DAQ System

CERN-EDUSAFE Meeting 28/10/13

Page 26: Safety System Modularity

CS System

CERN-EDUSAFE Meeting 28/10/13

Page 27: Safety System Modularity

Overall Integration Process

CERN-EDUSAFE Meeting 28/10/13

Page 28: Safety System Modularity

Delay or other issues

•PTU Phase 2 Specifications and hardware designs

• Use Cases

• PTU Architecture

• Hardware Designs

• Enclosure

• Integration Process

•Software - DAQ System

• DAQ PTU software

• DAQ Server softwa

• DataBase

• Messages format

• Delay or other issues

CERN-EDUSAFE Meeting 28/10/13

Page 29: Safety System Modularity

Delay or other issues

• We don’t have any delay for current milestone and overall studies carried out in a

perfect way. In addition, Some points have been noted as a risk for future milestones.

These are:

CERN-EDUSAFE Meeting 28/10/13

Risk Description Possible Effects Prevention Actions Possibility ESR 5 has not yet start working on D3.1

The architecture of the DAQ software and the interface to the Control system will be delayed.

We based on the DAQ system and protocols that were developed during the WPSS project making some improvements to overcome the issues that have been faced.

Medium

Missing detail specifications for AR system

The current PTU is not designed for AR. The electronic design for new PSS will be delayed because of missing detail specification for AR system.

We tried to design a very modular and open architecture in order to easily make adaptions and changes considering the AR in the future.

Medium

Important Feedback from potential end-users is not clear yet.

The design may need to change as per user requirements which can lead delay.

Feedback from potential customers can be taken.

Low

Page 30: Safety System Modularity

Upcoming Works

CERN-EDUSAFE Meeting 28/10/13

No. Major works Starts Finish Remarks 1 3D drafting of PSS Module July’13 September’13

2 PSS module HW/SW architecture design report September’13 October’13 with ESR 5

3 Finalize the system requirements October’13 November’13

4 Electronics design schematic, PCB for modular December’13 Jun’14

5 PSS adaptability with ESR 10 December’13 Jun’14

6 Construct the PCBs and assembly the components July’14 November’14

7 Electrical, optical testing on the 1st prototype December’14 May’15

8 Develop modular DAQ, Server DAQ Software July’14 August’15

9 Functionality test May’15 September’15

10 2st prototypes develop March’15 December’15

11 PSS, CS, DAQ Real conditions Test May’15 February’16

12 Performance evaluation March’16 June’16

Page 31: Safety System Modularity

Modular Concept

Page 32: Safety System Modularity

Q/A

CERN-EDUSAFE Meeting 28/10/13

Questions/Comments

Thanks to all