1 General

The ControlRoom is a PC application acting as the Diamond Parking Guidance System user interface.

The Diamond Parking Guidance System is a stand-alone system. It was designed so that its entire hardware can operate and provide guidance completely independent of any central control.

In other words, the system does not need the ControlRoom for its basic operation.

However, the ControlRoom application adds vital functionality far beyond mere guidance.

The main functions of the ControlRoom application are:

  • Real-time parking availability indication – The ControlRoom collects the availability/occupancy data from the entire system once every 2 seconds. Using the PC screen, the status of each bay is displayed on a geographical replica of the site.
  • Data logging– Every movement is recorded:

-    Type of movement In/Out.
-    Position of the movement.
-    Time of movement.

  • Data analysing – Graphical presentation of occupancy and activity per any number of bays for duration of day, week or month.
  • Saving, Printing, Reporting and exporting of data.
  • Real-time data exchange for communication with other applications.
  • Automatic fault detection, logging and reporting.

Besides its main functions, the PGS ControlRoom can assume full control over the system as follows:

  • It can control all space indicators.
  • It can control all the way finding devices.

The ControlRoom’s full control over the system is used mainly during commissioning.

2 Real-time parking status indication

The PGS ControlRoom application provides the parking management with a real-time status of the parking lot. The following screen shows one block of an actual site in operation:

m1.png

Block description:

  • The Block contains 128 parking bays.
  • 4 dead-end lanes, each defined as a Section.
  • 5 Paraplegic allocated parking bays – Blue signals available bay.
  • 18 VIP allocated parking bays – White signals available bay.
  • Also 13 privately owned bays with no sensors or indicators at all.

In order to guide drivers, 6 numeric displays are installed at decision-making points and give an approaching vehicle direction to the available bays. The availability information is, in this particular site, very important as it prevents drivers from entering dead-ends when they are full.

As can be seen, all the parking bays and numeric displays are projected on one page, giving the site operator an accurate real-time status of the site.

Using the “Block select” menu, other blocks representing other areas can be selected. The following is an example of a site with three blocks, each representing a different level.

m2.png

Should it be required, an entire site can be presented on multiple screens.

 

3 Show/Hide indicators and control

During normal operation, only the space indicators and the numeric displays are visible. Other indicators and controls are hidden in order to keep the screen clean and the actual occupancy information clear. The following screen shot describes a small section with ten parking bays and one numeric display.

m3.png

Using the Show/Hide menu the operator can display and hide the following controls and indicators.

m4.png

Due to limited screen area and the need to keep the screen clean, some of the controls when selected will cause others to be hidden.

Once any indicator or control is shown, the menu item changer to “Hide …” enabling the operator to hide the indicator or control and revert to a clean screen.

  3.1 Show/Hide Indicator watch

Each space indicator can be forced to be permanently red, green or off. Also it can be forced to blink. The main space indicator always shows the actual status of the parking bay, occupied or vacant. If the space indicator was forced to one of the modes other than normal, the indicator watch shows this mode.

m5.png

In the example all the space indicators have been forced to green. As can be seen, the main space indicators are showing the actual occupancy of the bay while the indicator watch are all permanently green.

3.2 Show/Hide Device labels

The device labels are optional string text that describes the location of each device and/or its allocation in the case of numeric displays. The labels serve to assist the parking management with the identification of bays, numeric displays and other devices.

m6.png

In the example
·    Each bay is marked with its section and number.
·    The numeric display is labelled with its allocation.

3.3 Show/Hide Device status

Each device of the Diamond Parking Guidance System has a built-in test. Please refer to the various datasheets for details. Upon detection of a fault in any device the following will happen:

·    A message pops up notifying the operator of the fault.
·    An SMS is automatically sent to the service centre requesting service.
·    The device is marked as faulty using its status indicator.

m43.png

The example shows one sensor that has reported a problem.
The counting of the available bays will assume that the information received is correct. This is because not all the faults affect the accuracy of the detection.

3.4 Show/Hide Device mode

Each space indicator can be forced to be permanently red, green or off. Also it can be forced to blink. This is done using the mode control.

m7.png

In the example all the sensors are set to normal.

Clicking on the arrow opens a selection box as follows:

m8.png

The operator can then select any of the modes.

When selecting “Show device mode” global selectors also appear. In the example the global mode selector is on the lower right of the screenshot. With the global selectors, an entire section, zone, block or allocation can be set with a single click.

3.5 Show/Hide Device Intensity

It may be required to control the intensity of the space indicators. The operator can select to show the intensity control and adjust the intensity to 15 intensity levels.

m9.png

When selecting “Show intensity control” a global intensity control also appears. In the example the global intensity control is on the lower right of the screenshot. With the global intensity control, the intensity of an entire section, zone, block or allocation can be set with a single click.

4 Data analysis

One of the main functions of the control room is to present the logged data in a meaningful statistical presentation.

The first step is selecting the parking bays that will participate in the analysis. Clicking on the “Data analysis” menu drops down with three options. When first clicked on, only the “Show bay selector” item is highlighted. Once selected, the bay selectors are displayed.

m10.png

The operator can now select the bays to participate in the data analysis:

·    Select the entire site using the “Select all” menu item which is now highlighted.

m11.png

·    Browse though all the blocks of the site and select or deselect any individual bay using its tick box bay selector.
·    Browse though all the blocks of the site and select or deselect any Block, Zone, Section or Allocation using the global tick boxes.

m12.png

In the example the 5 bays on the right have been selected.
When selecting “Show bay selector” global bay selectors also appears. With the global bay selector, bays of entire sections, zones, blocks or allocations can be selected with a single click.

Once at least one bay is selected the third menu item “Data and graphs” is highlighted.

m13.png

Selecting it will open the “Data analysis” window.

5 Graphs and statistics

The ControlRoom can analyse and produce the following graphs:
·    Occupancy distribution graph.
·    Activity distribution graph.

All graphs can be produced for day, week or for month.

When opened for the first time, the default is set to daily occupancy graph.

5.1 Occupancy mode

The following graph shows the occupancy pattern that took place at an actual site on Wednesday the 8th of January 2014.

As it is Daily graph, the vertical lines divide the day to 24 hours.

As it is Occupancy graph, the horizontal lines represent the percentage of full occupancy.

Cursor information in occupancy mode

Just above the graph two information boxes can be found. Moving the yellow cursor across the graph provides momentary information as per the position of the cursor

m14.png 

m16.png

m15.png

 

m17.png

 

5.2 Activity mode

Using the “Graph type” menu, the operator can select to view the activity distribution

m18.png

Cursor information in activity mode

Moving the yellow cursor across the green activity graph provides momentary information as per the position of the cursor

m19.png 

m20.png

m21.png

5.3 Browse through time

5.3.1 Day select

The operator can select a different day in the month using:

·    The day select slide.
·    Using the Next/Previous buttons.

5.3.2 Year and Month select

The operator can select different year and different month.

5.4 Zoom

The operator can zoom on a day, week or on a month by clicking on the Zoom menu and selecting the desired option.

m22.png

The following screen is a weekly occupancy graph. Moving the day select slide or the Next/Previous will move the beginning of the week respectively.

m24.png

The following screen is a monthly occupancy graph.

m25.png

Both graphs are of an office building as the weekend can be clearly seen.

All the other indicators provide the weekly or monthly information respectively.

5.5 Summary information

The summary information can be found at the foot of the graph. The following information is provided:

·    Number of parking bays selected for the graph.
·    Number of records found for the selected parking bays and for duration of the graph.
·    Occupancy ratio.

The Occupancy ratio is a percentage of the total accumulated occupancy to the site operating hours as entered in the configuration.

6. Saving and retrieving graphs

Once a daily, weekly or monthly graph is displayed it can be saved as a unique data file that includes all the information regarding the graph.

These files can be then emailed and read by other users.

·    To save a file go to the file menu and select “Save PGS file”
·    To load a file go to the file menu and select “Load PGS file”

m26.png

The ControlRoom application must be used in order to view saved files. Please note that JVES does not limit the number of installations of the ControlRoom software. 

7. Reports and Exports

7.1 Definitions

7.1.1 Report Vs. Export

Reports and export contain the same information with different format.

·    Report – .RTF Text file that can be read and used by any word processor.
·    Export – .CSV comma delimited text file that can be read into any database including Excel spreadsheet for further analysis.

Other file formats other than .CSV can also be generated. Consult with us regarding your particular requirement.

7.1.2 Period of Reports/Exports

Once a daily, weekly or monthly graph is displayed a Report/Export, relating to that period can be produced.

7.1.3 Resolution of Reports/Exports

Where applicable, the operator will be able to select the resolution of the report. For example, when producing Occupancy report for a period of a week the system will ask if the report should be for every day or every hour.

7.2 Types of Reports/Exports

The ControlRoom can produce a few types of Reports/Exports:

  • Occupancy Reports/Exports
  • Activity Reports/Exports.
  • Movements Reports/Exports.
  • Exception Reports/Exports
    • Over stay.
    • Under utilize



The following daily graph is from an actual site that serves a business community and a theatre. As can be seen the business users are arriving between 7:00 and 9:00 and leaving the site in the afternoon and the theatregoers are occupying it from 21:00 till midnight.

m27.png

The following graph is the activity graph of the same area

m28.png

One can easily see the link between the Occupancy graph and the Activity graph

7.2.1 Occupancy Reports/Exports

Selecting Report>Occupancy>Hourly from the menu as follows:

m29.png

Will bring a file select pop-up with the system recommendation for a file name.

m30.png

And will produce the following report:

m31.png

One can easily correlate the behaviour seen on the graph to the report.  

Selecting Export>Occupancy>Hourly from the menu as follows:

m32.png

Will also bring a file select pop-up and will produce the following export:

m33.png

As can be seen, both formats contain the same information. For the remainder of this document all the examples will be report examples.

7.2.2 Activity Reports/Exports

Following the same operation sequence but selecting Report>Activity>Hourly will produce the following report.

m34.png

Again, one can see that the activity pattern matches the activity graph.

7.2.3 Movement Reports/Exports

The movement Report/Export presents the logged data as follows:

Parking bay number  -- In time--- Out time

The following is a movement report that was produced for the same graph.

Upper screenshot – With the header of the report

m35.png

Lower screenshot – With the report summary

m36.png

 
7.2.4 Exception Reports/Exports

The purpose of the Exception Report/Export is to detect abnormal behavior patterns such as:
·    Over stay.
·    Under stay

7.2.4.1 Over stay Report/Export

Over stay is detected when a parking bay is continually occupied for longer than a predefined maximum stay period. For example, if the predefined maximum stay period is 23 hours, any vehicle parked for longer will be reported.

The following is an Over stay report that ran over a month.

m37.png

7.2.4.1 Over stay Report/Export

Over stay is detected when a parking bay is utilised for less than a predefined minimum stay period. For example, if the predefined minimum stay period is 8 hours per day for 5 days week, any vehicle parked for less than 40 hours per week will be reported.

The following is an under stay report that ran over a month.

m38.png

It must be noted that in this particular case, most of the under utilised bays were reserved for a group of employees. Based on the reports the management decided to add more employees to this group optimising the utilisation of the area.

8 Fault handling

By their nature, Parking Guidance systems extend over large areas with power supply and communication lines stretching over kilometres.

Also, they may involve thousands of hardware entities, sensors, numeric displays, power supplies, data buffers etc.

The customer cannot be expected to inspect such a system for proper operation and report problems should they happen.

Understanding this, Joint Ventures Electronic Services has introduced an extensive BIT, Built In Test, with automatic fault report.

The ControlRoom application scans the system for faults at regular intervals.

Upon a detection of a fault:
·    Popup is raised on the ControlRoom with the details of the fault.
·    A fault log is generated into a special file.
·    Our technician gets an automated SMS with the fault description.

In addition to the above, 4 Main statue LEDs are also provided at the bottom of the screen, giving the operator a quick indication of the system’s health.

m39.png

In our case, all 4 Main Status Indicators are green indicating that:
GSM – The GSM Modem is connected and detected.
Gateway - The Gateway device is connected and detected.
System communication – The system is communicating smoothly.
System hardware – No device has reported a fault or degradation.

8.1 Types of faults
There are two main types of faults that can be reported:
·    Communication faults.
·    Device faults.

8.1.1 Communication faults
The following diagram illustrates the system’s communication paths. There are 4 possible communication paths as follows:
1.    Main RS485 Bus - linking the Gateway device with the system.
2.    BlockBuffer RS485 Buses – Secondary RS485 communication paths, link each BlockBuffer with its downstream ZoneBuffers. The BlockBuffer buses are numerated as per their respective BlockBuffer BZ-Bus, BA-Bus, BB-Bus etc.
3.    ZoneBuffer RS485 – Further down RS485 communication paths, linking each ZoneBuffer with optional downstream RS485 devices. The ZoneBuffer buses are numerated as per their respective BlockBuffer and ZoneBuffer ZZZ-Bus, ZZA-Bus, ZZB-Bus etc.
4.    ZoneBuffer RS232 Bus – Further down RS232 communication paths, linking each ZoneBuffer with its array of sensors, numeric displays, Power supplies etc. The ZoneBuffer arrays are numerated as per their respective BlockBuffer and ZoneBuffer ZZZ-Array, ZZA-Array, ZZB-Array etc.

m40.png 

8.1.2 Device faults

Every Diamond PGS device was designed with a built-In-Test. The Built-In-Test performs a few basic functional tests and measurements.

For example, the function of the power supply is to deliver DC power to the power bus of the system.

1.    It must generate DC voltage.
2.    It must deliver current to the system.

The Built-In-Test verifies these two parameters.

1.    The voltage is measured and verified – Indicating whether the power supply is running OK.
2.    The current is measured and verified – Indicating whether the power supply is properly connected to the power bus.

The set of tests differs from device to device. Refer to each device datasheet for the list of tests and their respective message.

8.2 Faults detection timing

8.2 Communication fault detection timing

The ControlRoom collects data from the system every 2 seconds; therefore, by nature, communication faults are detected and reported immediately.

8.2 Device fault detection timing

The ControlRoom polls all the devices for faults at regular intervals. The default frequency is every hour. If a fault or degradation is detected, it will be reported after the poll sequence.

The poll rate can be increased, however we recommend a fault poll per hour in order not to load the communication lines with unnecessary traffic.

8.3 Faults Reporting

As already mentioned, upon a detection of a fault the ControlRoom takes the following steps:

·    Popup is raised on the ControlRoom with the details of the fault.
·    A fault log is generated into a special file.
·    Our technician gets an automated SMS with the fault description.

8.3.1 Fault pop-up

The fault pop-up is a list of all events that took place since the ControlRoom application has started.

m41.png

Each message is time and date stamped.

Once the ControlRoom Application is closed, the pop-up data is lost.

8.3.2 Fault log file

All the faults together with important system messages are logged.

The following is a screenshot of such a log.

m44.png

In order to create the log file faults have been simulated:

·    The ControlRoom application was started
·    A sensor was blocked.
·    A power supply was disconnected
·    RS485 line was disconnected
·    RS485 line was reconnected.
·    The block was removed off the sensor..
·    A power supply was reconnected
·    The ControlRoom application was closed

As can be seen, all the activities have been recorded. This enables the service centre to follow up on problems and correct them.

8.3.3 Service request

If enabled, the ControlRoom will send SMS messages with the details of the fault to the local service centre.

In addition, two other subscribers may be registered.

m42.jpg

The service request contains information describing the type of fault and its location. The service technician will arrive well equipped to deal with the issue and will go straight to the location of the faulty device.

9.1 Data sharing

With the development of mobile booking applications, it becomes necessary to provide real-time data interface.

The Diamond Parking Guidance System offers two methods of data sharing.

·    Active X.
·    Data file

The detailed description of these interfaces is beyond the scope of this document. Please consult JVES should you need further information.