Proposal for Comprehensive SINERGY Surveillance System. Group 12 John Kurlak Robert Pero Aleksi White

Transcription

1 Proposal for Comprehensive SINERGY Surveillance System Group 12 John Kurlak Robert Pero Aleksi White Architectural Model and Complete Design Specification April 27, 2012

2 1. Introduction Diverse incidents (such as acts of violence, gas leaks, and earthquakes) take place on campuses across the United States every day. To manage such incidents effectively, a comprehensive system is necessary. SINERGY (campus situational awareness and Emergency Response management system) is a Service-Oriented Architecture (SOA)-based network-centric system of systems, which offers a comprehensive, institution-wide, software-based solution for balancing safety and openness on any campus environment. 1 In this document, we propose an Architectural Model and Complete Design Specification for a Comprehensive SINERGY Surveillance System. The Architectural Model provides an overall picture of the system and its workings. The Complete Design Specification covers the details of the system by discussing the structure, organization, interactions, workflow, and sequencing. Our proposed architecture is modeled on the Microsoft.NET Platform and is designed to handle three major components: manual surveillance, automated surveillance, and situational awareness management. Each major component has been incorporated into our system using a Client- Server Architecture. Section 2 of this document describes the specifics of how our design works. Included in Section 2 is a detailed diagram of our network-centric system architecture, broken up into logical layers. Our proposed Complete Design Specification is detailed through numerous UML diagrams in Section 3. Section 3.1 covers the overall design of the system in terms of software classes and their relationships through a series of Class Diagrams. All aspects of the system are covered in this section. Section 3.2 uses a Component Diagram to show the organization and dependencies of the various SINERGY components in our system. Section 3.3 shows the devices and connections of our system in a Deployment Diagram. It shows where all surveillance systems reside and where all of the databases are deployed. Section 3.4 uses Statechart Diagrams to provide an overview of the possible states for different aspects of our system (such as user states, command center states, situational awareness states, etc.). Section 3.5 describes the workflow behavior of our system through a collection of Activity Diagrams. More specifically, it shows how operators can issue alerts and view surveillance as well as how campus constituents can report incidents. Section 3.6 provides a series of Sequence Diagrams to show the time-based object interactions for controlling, recording, and managing surveillance as well as for raising situational awareness. Next, Section 3.7 uses Collaboration Diagrams to detail how objects link together and how they send messages to each other in order to perform surveillance, accept reports, and raise situational awareness. Finally, Section 3.8 organizes the components of the system into related groups using a set of Package Diagrams. It groups the surveillance aspects of our system together, and it groups the command center aspects of our system together. Finally, Section 4 of our proposal offers concluding remarks regarding the entire system as a whole. If you have any concerns about our product, see Section 4. ii

3 Table of Contents 1. Introduction... ii 2. Network-Centric System Architecture Object-Oriented Software Design with UML Class Diagrams Manual Surveillance System Class Diagram Online Report Class Diagram Phone Report Class Diagram Mobile Message Report Class Diagram Visual Situational Awareness Class Diagram Audible Situational Awareness Class Diagram Noise Player System Class Diagram Monitor Surveillance Class Diagram Automated Surveillance Class Diagram Support Classes Class Diagram Mobile Message Sender Class Diagram Online Message Sender Class Diagram Component Diagram Overall System Component Diagram Deployment Diagram Surveillance System Deployment Diagram Statechart Diagrams Login Statechart Diagram Command Center Statechart Diagram User Access Statechart Diagram Command Center Options Statechart Diagram Raise Situational Awareness Statechart Diagram Activity Diagrams Operator Surveillance Activity Diagram Constituent Report Activity Diagram Operator Automated Alert Activity Diagram Operator Manual Report Activity Diagram Operator Issue Alert Activity Diagram Sequence Diagrams iii

4 Control Surveillance Sequence Diagram Monitor Surveillance Sequence Diagram Audible Situational Awareness Sequence Diagram Visual Situational Awareness Sequence Diagram Automatic Surveillance Sequence Diagram Collaboration Diagrams Report Incident Collaboration Diagram Raise Visual and Audible Situational Awareness Collaboration Diagram Surveillance Settings Collaboration Diagram Operator Surveillance Collaboration Diagram Send Electronic Message Collaboration Diagram Package Diagrams Surveillance Package Diagram Command Center Package Diagram Concluding Remarks References Appendix A: Meeting Minutes, Attendance, and Project Management Related Information Appendix B: Percentages of Contribution (with Signatures) iv

5 2. Network-Centric System Architecture Microsoft SQL Server Manual Surveillance Database Automated Surveillance Database ADO.NET A) Save/Retrieve Surveillance B) Change/Retrieve Surveillance Settings C) Activate/Deactivate Indicator Lights/Noise Playing System A) ViewSurveillance.aspx A) ViewManualSurveillance.aspx A) ViewAutomatedSurveillance.aspx B) UpdateSurveillanceSettings.aspx C) ControlIndicatorLights.aspx C) ControlNoiseSystem.aspx ASP.NET D) Post Mobile/ /Desktop/Social Media/LAN/Website Message E) Record/Play/Stop Audio Alerts F) Register/Login User D) PostMobileMessage.aspx D) Post Message.aspx D) PostDesktopMessage.aspx D) PostSocialMediaMessage.aspx D) PostLANMessage.aspx D) PostWebsiteMessage.aspx F) Login.aspx F) Register.aspx Index.aspx Common Language Runtime Engine Windows Server Operating System Server Request IIS Response Network (TCP/IP, HTTP, HTTPS) Client HTML CSS JavaScript JSON Web Forms Manual Surveillance System; Operator Automated Surveillance System User 1 User 2 User N Desktop, Laptop, Tablet, PDA, Smart Phone, Feature Phone, Landline Phone Node 1 Node 2 Node N Sound Sensors, Video Cameras, Door Security System, Weather Sensors 1

6 Our architecture is modeled on the Microsoft.NET platform. The inputs to our system are split between the automated surveillance systems, the manual surveillance systems, and the operator access devices. The automated surveillance system includes various automated sensors and cameras, while the manual surveillance system relies on campus constituents using various devices (phones, laptops, etc.) to report incidents. Inputs from the automated and manual systems are processed through centralized servers, and information is stored in the relational database management system, SQL Server. The operators also interact with the same server and can control surveillance system settings and incident indicators. First, we will consider the automated surveillance system. The automated surveillance system includes sound sensors, video cameras, weather sensors, and the door access security system. As these systems gather surveillance data, they send requests over the network to the IIS server. The IIS server then invokes the appropriate managed components in the business logic layer. These components are used to save the surveillance data to the database. This happens through interactions with ADO.NET, which maps data between the business logic layer and the data source layer, allowing the surveillance data to be stored in the SQL Server database. After the surveillance data is saved to the SQL Server database, the managed components then query the SQL Server database for the current surveillance settings. ASP.NET is used to relay this data back through the network as a JSON response to the client. The sensors, cameras, and security systems can then process that data locally and react according to the settings in case any changes were detected (such as a change in camera angle). Next, we will consider the manual surveillance system. The manual surveillance system consists of various campus constituents (students, faculty, staff, administrators, emergency response personnel) using various devices (mobile devices, computers, etc.) to report incidents. When a campus constituent makes a surveillance report, it is sent as a request over the network to the IIS server. The IIS server then invokes the appropriate managed components in the business logic layer to save the data to the database. This happens through interactions with ADO.NET, which maps data between the business logic layer and the data source layer, allowing the surveillance data to be stored in the SQL Server database. Furthermore, any Web Form necessary components from the.net Framework Component Class Library are rendered according to the request. ASP.NET is used to generate the dynamic response that is sent back through the network to the campus constituents indicating that the incident report has been saved. The data response is sent through the network to the client as HTML, CSS, JavaScript, and Web Forms. Finally, we will consider the command center operations. An operator can view the surveillance, change the surveillance settings, and raise situational awareness. To do this, he or she uses a device, such as a desktop computer, to make network requests to the IIS server. If the operator is trying to view the surveillance, the managed components in the business logic layer will query the database using ADO.NET. The surveillance data will then be sent through ASP.NET to the operator over the network as video, audio, images, HTML, CSS, and JavaScript. If the operator is trying to change the surveillance settings or activate situation indicators, the managed components in the business logic layer will send the new settings to the database using ADO.NET. The result of those changes will be sent through ASP.NET to the operator over the network as HTML, CSS, and JavaScript. If the operator is trying to raise online situational awareness, the managed components in the business logic layer will send out mobile messages, s, desktop messages, social media messages, LAN messages, and website messages. The 2

7 result of sending those messages will be reported back to the operator over the network via ASP.NET. The results will be sent as HTML, CSS, and JavaScript. We chose this client-server based system architecture running on the.net Framework because it is highly maintainable. The hardest and most expensive aspect of any software system is maintainability. By using a service-oriented architecture with client-server interactions, we can offer a system that is extremely easy to maintain and modify. Furthermore, our system architecture uses the Model-View-Controller (MVC) design pattern. MVC effectively allows us to separate the concerns of our system, making it easier to specialize and reuse the various components of our system. Due to these advantages, we believe that our system architecture is superior to the options offered by our competitors. 3

8 3. Object-Oriented Software Design with UML 3.1 Class Diagrams Manual Surveillance System Class Diagram Figure Manual Surveillance System Class Diagram The Class Diagram in Figure provides an overview of the classes involved when a campus constituent reports an incident manually. The campus constituent, represented as a User, files a Report. If the user files a report online, an OnlineReport is created. If the user 4

9 files a report via a landline phone, a PhoneReport is created. If the user files a report via text message, a MobileMessageReport is created. 5

10 Online Report Class Diagram Figure Online Report Class Diagram The Class Diagram in Figure describes how an online report is represented in our system. The PerpDescription class provides a set of fields for describing a perpetrator if one was present. The InputValidator assists in validating user input from the online report form. The DatabaseWrapper makes it easy to store the report form data in the database. 6

11 Phone Report Class Diagram Figure Phone Report Class Diagram The Class Diagram in Figure describes how a landline phone report is represented in our system. The PerpDescription class provides a set of fields for describing a perpetrator if one was present. The InputValidator assists in validating user input from the online report form. The DatabaseWrapper (which uses ADO.NET) makes it easy to store the phone report data in the database. 7

12 Mobile Message Report Class Diagram Figure Mobile Message Report Class Diagram The Class Diagram in Figure describes how a mobile phone report is represented in our system. The TextMessage class can parse incoming text messages and can send text message. It is used to retrieve incoming text message reports and to send out Thank You messages. The DatabaseWrapper (which uses ADO.NET) makes it easy to store the report data in the database. 8

13 Visual Situational Awareness Class Diagram Figure Visual Situational Awareness Class Diagram The Class Diagram in Figure shows how an operator can raise visual situational awareness. An operator can use the VisualSituationalAwarenessRaiser class to control the IndicatorLightSystem. The IndicatorLightSystem provides a number of control options as methods. The InputValidator is used to validate settings that the user selects. The DatabaseWrapper (which uses ADO.NET) makes it easy to store the indicator light settings in the database. 9

14 Audible Situational Awareness Class Diagram Figure Audible Situational Awareness Class Diagram The Class Diagram in Figure shows how an operator can raise audible situational awareness. An operator can use the AudibleSituationalAwarenessRaiser class to control the NoisePlayerSystem. The NoisePlayerSystem provides a number of audio control options as methods. The InputValidator is used to validate settings that the user selects. The DatabaseWrapper (which uses ADO.NET) makes it easy to store the audio settings in the database. 10

15 Noise Player System Class Diagram Figure Noise Player System Class Diagram The Class Diagram in Figure describes how the NoisePlayerSystem works. An audio file can be played or stopped across campus speakers using the NoisePlayerSystem class. The NoisePlayerSystem class is broken into two systems: the RecordedSpeechPlayerSystem and the AlertNoisePlayerSystem. The RecordedSpeechPlayerSystem allows an operator to record a piece of audio or select a prerecorded piece of audio and then play it. The AlertNoisePlayerSystem allows an operator to select the type of incident on campus and then play an alert sound corresponding to that incident. 11

16 Monitor Surveillance Class Diagram Figure Monitor Surveillance Class Diagram The Class Diagram in Figure shows the association between the SurveillanceMonitor and the DatabaseWrapper, as well as the SurveillanceMonitor and its subclasses, SurveillanceController and SurveillanceViewer. Each of these subclasses inherit the methods from their parent, as well as use the DatabaseWrapper (which uses ADO.NET) to connect to the surveillance database. 12

17 Automated Surveillance Class Diagram Figure Automated Surveillance Class Diagram The Class Diagram in Figure shows all the constituent parts of the automated surveillance system (its subsystems), as well as the system s association with the DatabaseWrapper (which uses ADO.NET). The wrapper is used to record results from the subsystems into the database. 13

18 Support Classes Class Diagram Figure Support Classes Class Diagram The Class Diagram in Figure shows the association between various support classes and their association with three of the subsystems of the automated surveillance system. The support classes define elements identified by the automated surveillance system. 14

19 Mobile Message Sender Class Diagram Figure Mobile Message Sender Class Diagram The Class Diagram in Figure describes how a mobile message is sent to users of the alert system. TextMessage is used to specify the sender and recipient of the text message, which also includes a subject and message body. InputValidator validates the selections made by the user. DatabaseWrapper (which uses ADO.NET) makes it easy for the user to store text message settings. 15

20 Online Message Sender Class Diagram Figure Online Message Sender Class Diagram The Class Diagram in Figure describes how an online message is sent to users of the alert system. MessageType is used to specify the type of message a user wants to send along with a customized message. InputValidator validates the selections made by the user. DatabaseWrapper (which uses ADO.NET) makes it easy for the user to store mobile message settings. 16

21 3.2 Component Diagram Overall System Component Diagram Figure Overall System Component Diagram The Component Diagram in Figure gives an overall picture of the system components and their interfaces. The CommandCenterInterface is at the core of the system. It can be used to view and control surveillance as well as to raise situational awareness. The surveillance system depends on the SurveillanceDB (a SQL Server Database), which it uses to store surveillance data. 17

22 3.3 Deployment Diagram Surveillance System Deployment Diagram Figure Surveillance System Deployment Diagram The Deployment Diagram in Figure shows the locations of all aspects of the automated surveillance system. All surveillance devices, as well as the command center, are located on or around campus. The database resides at a secure location in Nova Scotia, at coordinates [information redacted]. 18

23 3.4 Statechart Diagrams Login Statechart Diagram Figure Login Statechart Diagram The Statechart Diagram in Figure describes a specific behavior showing different states within the Distress alert system. The initial state provides No Access to the operator until the proper credentials are entered. Once acceptable credentials are entered, an operator will receive Access to the system and may proceed with a Command. If the system is idle, an operator s current session may time out, unless the operator decides to logout beforehand. 19

24 Command Center Statechart Diagram Figure Command Center Statechart Diagram The Statechart Diagram in Figure describes a specific behavior showing different states within the Distress alert system; in this case, a general view of the system. The initial state provides an operator with a Login prompt. Once logged in, the system is unlocked to the operator, providing access to the Command center. From this point, the operator is presented with a set of Options, allowing for different commands to be assigned. 20

25 User Access Statechart Diagram Figure User Access Statechart Diagram The Statechart Diagram in Figure describes a specific behavior showing different states within the Distress alert system; in this case, a look at the level of access provided to specific users of the system. The initial state commences with Restricted Access to all users, unless the user using the system is one of the following: an Operator, Administrator, Message Dispatcher, and/or Security Provider. Depending on the user accessing the system, they are provided either Limited or Unlimited access to the Command Center. 21

26 Command Center Options Statechart Diagram Figure Command Center Options Statechart Diagram The Statechart Diagram in Figure describes a specific behavior showing different states within the Distress alert system; in this case, a broader look of the systems options. The initial state begins with the Command Center providing two types of options. Once an option is selected, Feedback is collected and reported back to the Command Center. 22

27 Raise Situational Awareness Statechart Diagram Figure Raise Situational Awareness Statechart Diagram The Statechart Diagram in Figure describes a specific behavior showing different states within the Distress alert system; in this case, showing the intricacies of Raise Situational Awareness. The initial state begins with the Command Center, where an operator selects to Raise Situational Awareness. Upon selection, the operator is presented with three options: Visual Situational Awareness, Audible Situational Awareness, and Electronic Message. The operator can select one, two, or all three of these options. Once all viable options are selected, their actions are sent, thus finishing the selection process, and returning the operator back to the initial state of the Command Center. 23

28 3.5 Activity Diagrams Operator Surveillance Activity Diagram Figure Operator Surveillance Activity Diagram 24

29 The Activity Diagram in Figure shows what happens when the operator logs in to either view or control certain devices of the surveillance monitor. The operator can either view or control the surveillance system, and each of these accesses is recorded to the database. 25

30 Constituent Report Activity Diagram Figure Constituent Report Activity Diagram The Activity Diagram in Figure shows the various ways that a campus constituent can report an incident that he or she sees. This can be done online, over the phone, or via a text message. 26

31 Operator Automated Alert Activity Diagram Figure Operator Automated Alert Activity Diagram 27

32 The Activity Diagram in Figure shows what happens when the operator is issued an alert by the automated surveillance system. The alert can either be ignored and cleared as a false positive, or acted upon. In the latter case, the appropriate parties are notified. 28

33 Operator Manual Report Activity Diagram Figure Operator Manual Report Activity Diagram 29

34 The Activity Diagram in Figure shows what happens when the operator receives a report from the manual surveillance system. The report can either be ignored and cleared as a false positive, or acted upon. In the latter case, the appropriate parties are notified. 30

35 Operator Issue Alert Activity Diagram Figure Operator Issue Alert Activity Diagram The Activity Diagram in Figure elaborates on what happens when an operator issues an alert. Aside from notifying first responders and police, the campus administrators are notified. If the threat is immediate, the warning sirens are activated. If it is a future threat, then , text, and online reports are made available. 31

36 3.6 Sequence Diagrams Control Surveillance Sequence Diagram Figure Control Surveillance Sequence Diagram The Sequence Diagram in Figure shows the time-based sequence of events that go on in our system when an Operator tries to control the surveillance system. The Operator first logs in into the CommandCenter. Then, upon accessing the Control Surveillance page, the system retrieves the surveillance settings from the SurveillanceViewer. The Operator then can change any of the existing surveillance settings from his or her control panel. When the Operator goes to save the changes, the system sends the changes to the SurveillanceController, which saves them in the database. The result of the change is sent back to the Operator. 32

37 Monitor Surveillance Sequence Diagram Figure Monitor Surveillance Sequence Diagram The Sequence Diagram in Figure shows the time-based sequence of events that go on in our system when an Operator tries to monitor the surveillance. The Operator first logs in into the CommandCenter. Then, upon accessing the Monitor Surveillance page, the system retrieves the surveillance data from the SurveillanceViewer and relays it back to the Operator. The Operator can make additional requests for surveillance data as necessary. 33

38 Audible Situational Awareness Sequence Diagram Figure Audible Situational Awareness Sequence Diagram The Sequence Diagram in Figure shows the time-based sequence of events that go on in our system when an Operator tries to raise audible situational awareness. The Operator first has the option of using the AudioRecorder to record an audio message. Next, the Operator selects the audio file to play over the SpeakerSystem. The Operator then can play and stop the audio file as necessary to raise audible situational awareness. 34

39 Visual Situational Awareness Sequence Diagram Figure Visual Situational Awareness Sequence Diagram The Sequence Diagram in Figure shows the time-based sequence of events that go on in our system when an Operator tries to raise visual situational awareness. The Operator first selects the type of incident for the IndicatorLightSystem. Then the Operator can activate the indicator lights in the IndicatorLightSystem. After the lights are on, the Operator can change the indicator light color or pulsate frequency. When the incident subsides, the Operator can deactivate the indicator lights. 35

40 Automatic Surveillance Sequence Diagram Figure Automatic Surveillance Sequence Diagram The Sequence Diagram in Figure shows the time-based sequence of events that go on in our system when automatic surveillance is performed. The system starts by connecting to the database through the DatabaseWrapper (which uses ADO.NET). When the connection is authenticated, SurveillanceDevices can begin to send surveillance data to the AutomatedSurveillanceSystem. The AutomatedSurveillanceSystem then inserts the surveillance data into the database through the DatabaseWrapper. The DatabaseWrapper then sends the device s latest surveillance settings back to the AutomatedSurveillanceSystem. The AutomatedSurveillanceSystem then forwards the settings to the SurveillanceDevice. The SurveillanceDevice reads in the settings and then performs any appropriate actions, such as changing the viewing angle. 36

41 3.7 Collaboration Diagrams Report Incident Collaboration Diagram Figure Report Incident Collaboration Diagram The Collaboration Diagram in Figure shows how Report objects are sent through the ReportSystem to the ManualSurveillanceDB (a SQL Server Database). It also shows how an Operator can send a message to the ReportSystem to retrieve all of the manual surveillance reports that have been filed. 37

42 Raise Visual and Audible Situational Awareness Collaboration Diagram Figure Raise Visual and Audible Situational Awareness Collaboration Diagram The Collaboration Diagram in Figure shows how an Operator can raise visual and audible situational awareness. The Operator can send messages to either the IndicatorLightSystem or the NoisePlayer system. The IndicatorLightSystem can then forward the appropriate messages on to the IndicatorLights. Similarly, the NoisePlayerSystem can forward the appropriate messages on to the Speakers/Intercoms. 38

43 Surveillance Settings Collaboration Diagram Figure Surveillance Settings Collaboration Diagram The Collaboration Diagram in Figure shows the process by which a surveillance device interacts with the database. It saves all its information to the database, and receives new settings if they are available. The automated surveillance system acts as the mediator. 39

44 Operator Surveillance Collaboration Diagram Figure Operator Surveillance Collaboration Diagram The Collaboration Diagram in Figure shows how an operator controls the automated surveillance database. New settings are saved in the database, which are uploaded to the automated surveillance system. The system will in turn send its new results back to the operator through the database. 40

45 Send Electronic Message Collaboration Diagram Figure Send Electronic Message Collaboration Diagram The Collaboration Diagram in Figure shows the order of messages implemented within the Distress alert system. An Operator in this particular instance assesses a situation and selects an Electronic Message as a means of alerting system participants. The interaction between the objects consists of selecting an option in the command center, sending a message, and returning back to the command center; waiting for the next command from the Operator. 41

46 3.8 Package Diagrams Surveillance Package Diagram Figure Surveillance Package Diagram The Package Diagram in Figure shows how the surveillance system can be broken up into two generic packages: the manual surveillance system and the automated surveillance system. The diagram then describes the packages that make up both the automated surveillance system and the manual surveillance system. 42

47 Command Center Package Diagram Figure Command Center Package Diagram The Package Diagram in Figure shows the logical path an Operator may take when deciding how to perform in an emergency situation. Two of the major components will either collect data through Monitor Surveillance On-Demand and/or alert system participants. The parallel structure conveys the parallel roles of each package. 43

48 4. Concluding Remarks Our Architectural Model and Complete Design Specification successfully implement SINERGY in a way that you can trust. Supported by the.net Framework and a client-server architecture, our system is robust and easy to manage. Due to the service-oriented nature of our design, it is easy to integrate additional security systems into our solution. This means that you can always stay up to date on the newest security and surveillance technologies without having to buy a completely new system. We expect our Architectural Model and Complete Design Specification to be relevant for many years to come. If you have any questions or concerns, please contact our Sales Department. 44

49 References [1] [2] [3] 20Framework%20Overview.pdf [4] Tutorial.pdf [5] 0System%20Modeling.pdf [6] [7] [8] tbn0.google.com/images?q=tbn:and9gcsbbykp00ljculifl1pf84zmsdtwpu0zexu0umrlg-- QbylS-E9 [9] cctv-camera.jpg [10] 45

50 Appendix A: Meeting Minutes, Attendance, and Project Management Related Information Date Time Attendance Summary April 11 5:15 5:20pm John, Aleksi, Robert Decided when and where to meet April 17 9:30 12:00pm John, Aleksi, Robert Read over project requirements; worked on Architecture Design April 19 11:30 11:45 am John, Robert Showed Architecture Design to Dr. Chigani April 24 9:30 10:00 am John Setup document structure April 24 10:00 12:30 pm John, Aleksi, Robert Worked on Class Diagrams April 24 7:00 9:00 pm John Wrote Introduction; revised Architecture Design April :15 pm 1:00 am Aleksi Worked on Class Diagrams April 26 11:00 4:30 pm John, Aleksi, Robert Created remaining diagrams April 26 8:30 9:00 pm Aleksi Worked on remaining diagrams April 26 6:00 pm 4 am Robert Worked on remaining diagrams April :00 pm 2 am John Compiled diagrams into document and wrote descriptions for each diagram April 27 9:00 am 10:45 am John Compiled document April 27 2:00 pm 3:30 pm John Compiled document 46

51 Appendix B: Percentages of Contribution (with Signatures) John Kurlak: % Aleksi White: % Robert Pero: % 47