About marioverhaeg

Question   Are there technical measures for data protection in the context of BVMS Person Identification?   Answer   This article aims to provide concerned parties, such as customers, users, operators or consultants, with an overview of data privacy and protection related features of BVMS Person Identification. Moreover, this article describes how data, as processed during the Person Identification steps, can be classified. Finally, this article lists technical measures for data protection in the context of BVMS Person Identification.     Importance of GDPR   The General Data Protection Regulation 2016/679 (GDPR) on the protection of natural persons with regard to processing of personal data and on exchange of such data became effective on 25 May 2016 and is repealing existing EU Directive 95/46/EC. The GDPR regulates the processing (handling) of personal data in the European Union. The objective is to protect the fundamental rights and freedom of natural persons and in particular their right of protection of personal data. Personal data are all the information which relate to an identified or identifiable natural person, for example, names, addresses, telephone numbers or e-mail addresses which are or can be the expression of the identity of a person. Special categories of personal data in the sense of GDPR are information about a person, which are especially protected by the GDPR and therefore the data processing is subject to strict conditions. Special categories of personal data are, for example, racial or ethnic origin, genetic data, health data or biometric data. Art. 4 GDPR contains definitions of these terms. Before processing any personal data the national legal framework (see 3 Legal Framework) must be examined. We recommend to contact the responsible supervisory authorities in order to eliminate legal uncertainties.   Data Privacy and Protection at Bosch   Worldwide, some 1,000 associates work for Bosch as data security officers and data security partners. They provide their colleagues with advice on matters of data protection and information security. In consequence, data protection and data security are firmly anchored in the development process for new products and services. We will not start marketing these until we have proven – e.g. by means of penetration tests – that our data protection and security measures are effective. We assign our in-house data-protection and IT-security experts to development projects to make sure these aspects are given full consideration at all times.   How Does Person Identification Work?     During the Person Identification steps, personal data (i.e. photo and video), including special categories of personal data (i.e. biometric data), are processed by the system.   Legal Framework   Legislation Region Summary GDPR European Union Using the video surveillance system requires a legal framework. The GDPR is the legal basis for processing of personal data in Europe. Examples for the legal framework for processing of personal data are Art. 6 (1) GDPR and Art. 9 (2) GDPR, if special categories of personal data are processing, e.g. biometric data. Guidelines published by official authorities and / or boards, such as the European Data Protection Board (EDPB) Guidelines 3/2019 on processing of personal data trough video devices can be helpful to give an orientation for the evaluation. National regulations European Union Use of a video surveillance system can be also regulated in national regulations (Art. 9 (4) GDPR). The relevant national regulations should be examined. National regulations Non-European Union Use of a video surveillance system can be regulated in national regulations. The relevant national regulations should be examined.   Processing of Personal Data and Special Categories of Personal Data   Video Surveillance System   A video surveillance system processes (including display as well as storage) a huge amount of data. However, such a system can at most automatically classify the type of an object (person, car, bike), but not classify the identity of that object. This functionality allows, for example, an operator to search for "persons" or "cars", but does not allow him to search for person "John Doe" or for the car with license plate "M-12345". As a result, most of the data processed by a traditional video surveillance system is classified as ("normal") personal data and listed in the table below. Data type Definition Video Frame Single frame out of a video stream. Video Recordings Video Stream. Recording Time Camera Timestamp (visible or invisible) which is stored in the video recordings. Recording Location Camera Location data which enable the correlation of camera id and its position. Person Trajectory (Single Camera) Data consisting of multiple location and time entries to describe movement patterns in a single camera`s field of vision. Person Trajectory (Multiple Cameras) Data consisting of multiple location and time entries to describe movement patterns combined over multiple cameras. Event Log (Id. Events, DB Modifications) Logbook in BVMS.   Video Surveillance System with Person Identification   New technologies enable the system to uniquely identify persons who are captured by the cameras connected to the video surveillance system. Once the system is able to uniquely identify persons, some of the data is considered Special Category of Personal Data in the sense of GDPR. This allows, for example, the operator to add the picture of "John Doe" to the system and have the system notify him when "John Doe" appears in front of one of the cameras. When extending BVMS with the Person Identification functionality, the data listed in the table below is processed in addition to the data listed above, which includes a special category of personal data in the sense of GDPR, i.e. biometric data. Data type Definition Content Classification Passport Photo Used as Input for "Facial Vector from Passport Photo". Also stored (raw) in "Subject Database". Single Person Personal Data Name Name in clear text for subject management in "Subject Database". Single Person Personal Data Facial Vector from Passport Photo Facial Vector generated from "Passport Photo" as input for the "Subject Database". Single Person Special Category of Personal Data Facial Vector from Video Facial Vector generated from video data (multiple sources). Single Person Special Category of Personal Data Subject-ID Subject-ID generated for each new subject entry in the "Subject Database". Single Person Personal Data Subject Database Subject list with multiple entries of "Name", "Passport Photo", "Facial Vector from Passport Photo" and "Subject-ID", organized in groups. Multiple Persons Special Category of Personal Data Identification Event Successful identification of a facial vector. The event in the Log will contain: Time, (Camera)-Location, Subject-ID Single Person Personal Data   System Architecture   The video data and metadata (without person identification) is generated by the camera, and if recording of this data is enabled, is stored on an iSCSI drive. This video data can be replayed and the metadata generated by the camera can be searched for specific events. The video data itself, and the related metadata, is considered personal data. Additionally system events, actions and alarms are stored in the BVMS Logbook which is located on the BVMS MS (Management Server).   If the Person Identification functionality is enabled, the camera video data is also sent to the Person Identification Device (PID). The PID first attempts to find faces in the video. Once a face is detected, its facial features are determined and translated in a so-called face vector. A face vector is a unique mathematical representation of the face of a person. Every time this specific person appears in front of any camera, a face vector is generated. This allows the system to identify a specific person, even though this person is recognized in a different location under different circumstances (e.g. differing camera angles, varying light conditions, etc.). As the face vector can be used to uniquely identify a person, this is considered biometric data. Based on this functionality, the security operator is able to instruct the system to search for a specific person. This is done by adding a photo of a person's face to the subject database. Managing the subject database is done from the BVMS Operator Client. Once a subject is added, the Operator Client sends the photo to the PID. Using the process described above, the PID searches for a single face in that photo, and generates a face vector. Both the photo and the face vector are stored in a subject database on the PID. Once The PID has detected a face, it compares the face vector of the detected person in front of the camera with the face vectors stored in the subject database. If it finds a match between the two face vectors, it means that the system has detected a subject and an event is send to the BVMS Management Server. Depending on the configuration this event can be stored for later investigations. If the PID cannot find a match between the detected face vector and the subject database, the detected face vector is discarded and not stored within the PID. Besides the PID specific description, data protection in general is explained in the document BVMS - Securing the Security System.   Technical Measures   This section describes the technical measures that are available to manage both the personal and the special category of personal data in the sense of GDPR, i.e. biometric data. The technical measures outlined below follow a privacy by design approach.     Authorization and access rights management   BVMS has extensive authorization and access rights management. User groups (which can also be related to an enterprise user management environment) can be created, and can contain multiple users. For each user group, operating and configuration permissions can be set. Following the privacy by design approach, the system contains, by default, two user groups: for the "Admin Group" all permissions are set, whereas for the "Operator Group" only the essential operator permissions are enabled. Access rights management itself (modifying who has access to the system and which functionality is permitted) is, by default, available for the "Admin Group", but can be (optionally) enabled for other user groups as well.   The following functionality can be restricted by user group: PTZ control of dome cameras Allegiant trunk lines Print and save; Alarm display Playback; Logbook access Operator event buttons Close operator client Minimize operator client Audio Intercom Manual alarm recording Set reference image Change password Arm intrusion panel Force arm intrusion panel areas Disarm intrusion panel areas Bypass intrusion panel points Unlock intrusion panel doors Secure and unsecure intrusion panel doors cycle intrusion panel doors Person management. The login can be restricted with a login schedule, the access to specific devices can be enabled or disabled and the event subscription can be tailored.   Authentication   The users of the system are authenticated based on their user name and password. The system contains account policies which allow the system administrator to enforce the usage of strong passwords, including a minimum password length, and a maximum password age. To further decrease the risk of misusing data a four-eye principle can be applied on the login process (dual authorization). This means that two users need to authenticate themselves for login before the system enables them to access the defined system's functionality.   Pseudonymization and data erasure   For each event that is triggered by the system it is possible to configure whether the event is transformed into an alarm (notifying the operator of the event) and whether the related event data is stored into the BVMS Logbook. For each camera managed by the system, the recording parameters (including the minimum and maximum retention time) can be configured as described in the BVMS - Policy Based Recording article. The biometric data stored in the BVMS logbook as well as the personal data stored in the video archives can be removed by operators who have the permissions for this user action.   Input control   The system contains two log locations: The BVMS Logbook (an SQL database, with own authorization and access rights management) stores the events configured in the configuration of the system. In addition, it stores user actions (for example, when an operator calls up a camera or adds a person to a subject list) as well as system events (e.g., device disconnected or storage state failure). The BVMS Logbook itself can also be restricted in its retention time. The system log files, which can be used for debugging and detailed investigations, are stored in the file system of the server or workstation (C:\Programdata\Bosch\VMS\Log). For example, finding the source of an unauthorized login requires the usage of the system log files. The retention time of the log files differs depending on the purpose of the specific log file and the application, but is typically set to 200MByte (the actual time is depending on the amount of log data being generated and therefore to the usage of the system).   Customer self-service   As video surveillance systems are typically not accessible for the public this section is not applicable.   Encryption   Information related to specific software security measures are described in the BVMS - Securing the Security System article.   Threshold Probability   Default: 55%; Minimum 0%; Maximum 100% The similarity of a detected face and a reference photo in the database is expressed as a percentage between 0% and 100%. The higher this number is, the higher is the probability that the two faces are the same person. The threshold probability defines the threshold, above which the system considers it a match and triggers an alarm.    Recommendations for on-premise solutions   The BVMS - Securing the Security System recommends how to handle the system configuration from an IT security perspective, while the BVMS Network Design guide gives recommendations on how to set up the network infrastructure. Bosch recommends involving an IT security/network specialist to ensure these recommendations fit to your specific IT infrastructure.   Nice to know: BVMS 12.0 introduced the new AI-based Privacy overlay. The AI-based Privacy overlay removes personal data from videos by pixelating the whole person without exposing their unique identity, ensuring compliance with data protection laws and regulations worldwide. Learn more > ... View more

Possible causes and solution(s)   Causes   As video surveillance use grows in commercial, government and private use cases, the need for low-cost storage at scale is growing rapidly. BVMS, Bosch cameras, HPE hardware and SUSE Enterprise Storage provide a platform that is an ideal target for recording these streams. There are numerous difficulties around storing unstructured video surveillance data at massive scale. Video surveillance data tends to be written only once or become stagnant over time. This stale data takes up valuable space on expensive block and file storage, and yet needs to be available in seconds. With this massive scale, the difficulty of keeping all the data safe and available is also growing. Many existing storage solutions are a challenge to manage and control at such scale. Management silos and user interface limitations make it harder to deploy new storage into business infrastructure. The solution is software-defined storage (SDS). This is a storage system that delivers a full suite of persistent storage services via an autonomous software stack that can run on an industry standard, commodity hardware platform. Bosch, Hewlett Packard Enterprise (HPE) and SUSE have partnered to deliver the benefits of SDS to the video surveillance industry. Using SUSE Enterprise Storage™ on HPE ProLiant DL and Apollo servers in a Bosch video surveillance environment simplifies the management of today’s volume of data, and provides the flexibility to scale for all enterprise storage needs.   Solution   Scalability   Video surveillance systems need to store large numbers of data. To enable security operators to effectively manage security incidents when they happen, this data also needs to be available at all times. Based on the Bosch Video Recording Manager, SUSE Enterprise Storage and the HPE line of density-optimised servers, a scalable storage solution on different levels can be achieved. Scalability meets adaptability with HPE's line of density-optimised servers: Powerful computing with multiple systems on a chip (SoC), Speed of provisioning and the time to service are increased with built-in fibre and software for connectivity, scalability and adaptability. Make your move toward modular, hyper scale and ultra-converged infrastructure. On top of the physical server infrastructure, SUSE Enterprise Storage allows for unlimited scalability with a distributed storage cluster designed to scale to thousands of nodes and multi-hundred petabyte environments and beyond to meet the growing data requirements. Last, but not least, the Bosch Video Management System (BVMS) allows to scale up to 256 petabyte per system of 2000 cameras. Multiple BVMS systems can be combined into a massive BVMS Enterprise system, potentially spread out across the world. Existing BVMS systems can be easily expanded using a scale-out configuration: just add a new storage system to the Bosch video surveillance environment and the system will automatically take this into it's virtual pool of available storage capacity. There is no need to re-assign cameras to NVRs or re-configure NVRs to use a different storage system. All of this data is put at the fingertips of a video surveillance security operator. With Forensic Search, the operator can browse recorded images based on movement, but also on criteria, like the size or colour of objects. So, with just a few clicks, huge data volumes can be searched for all objects recognized as, for example, a person or a yellow taxi.   Performance   HPE's high-density server family delivers breakthrough performance with efficient rack-scale compute, storage, networking, power and cooling for your most demanding massive data analytics and object storage workloads. The latest iteration of Ceph, available in SUSE Enterprise Storage, offers BlueStore, which doubles the write performance of previous releases and significantly reduces input and output latency. The ability to provide a write-back cache tier enables the system to also service high performance short-term streams where only a percentage of requests actually end up being served from the long-term archive. The Bosch Video Recording Manager automatically balances the load across the available (SUSE Enterprise) storage targets, depending on a target specific performance configuration. This allows for very flexibly configurations, in which lower performance storage systems can be combined with high performance storage systems, while distributing the load on those systems accordingly.   Availability   HPE InfoSight gathers operational intelligence from an infrastructure by analysing millions of sensors across a globally-connected installed base, and using behavioural data provides trend insights, forecasting and recommendations, to predict and prevent problems. The result is higher efficiency and reliability, creating a smarter, easier-to-manage infrastructure for customers. SUSE Enterprise Storage comes with erasure coding, which lets you define the settings for data protection. You can determine how many device failures your cluster can tolerate before considering the data compromised. Compared to other video management systems BVMS allows for maximum resilience. This means continuous live and playbacks – no matter what happens. While other systems require you to add redundant components to create a resilient system, BVMS offers several levels of resilience out of the box. As a result, cameras keep recording and streaming live video even when multiple system components fail simultaneously.   Data Security   HPE is the only vendor to provide silicon root of trust on Gen10 servers, which creates a digital fingerprint in the silicon and ensures that the server will never boot with compromised firmware. This root of trust and other unique security features have garnered HPE recognition for having the “world’s most secure industry-standard servers. The SUSE Enterprise Storage operating system supports trusted boot scenarios to ensure that only signed kernels and drivers can be booted from and loaded. Because video data is often highly critical and sensitive, Bosch is driving a systematic approach to maximize data security by considering physical safety and cybersecurity simultaneously.   Proven configuration   The combination of SUSE Enterprise Storage, HPE and Bosch video surveillance components has been extensively tested. Not only the performance of the solution has been proved: several failure scenarios are considered to ensure the system continues to operate as expected.   Technology   SUSE Enterprise Storage - Powered by CEPH   Introduction   Ceph is the most popular OpenStack software-defined storage solution on the market today. It is extensively scalable from a storage appliance to a cost-effective cloud solution. It also provides industry-leading storage functionality such as Unified Block and Object, Thin Provisioning, Erasure Coding, and Cache Tiering. What's more, it is self-healing and self-managing.   Architecture   There are three primary roles in the SUSE Enterprise Storage cluster covered by this sample reference configuration: OSD Host—Ceph server storing object data. Each OSD host runs several instances of the Ceph OSD Daemon process. Each process interacts with one Object Storage Disk (OSD), and for production clusters, there is a 1:1 mapping of OSD Daemon to logical volume. The default file system used on each logical volume is XFS, although Btrfs is also supported. Monitor (MON): Maintains maps of the cluster state, including the monitor map, the OSD map, the Placement Group Map, and the CRUSH map. Ceph maintains a history (called an “epoch”) of each state change in the Ceph Monitors, Ceph OSD Daemons, and Placement Groups (PGs). Monitors are expected to maintain quorum to keep an updated cluster state record. Administrator: This is the self-master and hosts openATTIC, the central management system which supports the cluster. RADOS Gateway (RGW)—Object storage interface to provide applications with a RESTful gateway to Ceph Storage Clusters. The RADOS Gateway supports two interfaces: S3 and Swift. These interfaces support a large subset of their respective APIs as implemented by Amazon and OpenStack Swift. A minimum SES v4 cluster should contain: One administrator (typically a ProLiant DL360 server) Three or more MON nodes (typically ProLiant DL360 servers) Three or more OSD nodes (recommended Apollo 4000 servers) One or more RGW (typically ProLiant DL360 severs) Optional: iSCSI gateway (one or more ProLiant DL360 server) Density-optimized Apollo 4000 servers are ideal for use as the bulk storage OSD nodes. Ceph supports mixing Apollo 4000 server types and generations, enabling seamless growth with current technologies.   Keeping data safe   SUSE Enterprise Storage brings Ceph’s flexibility to bear by supporting data replication as well as erasure coding. Erasure coding mathematically encodes data into a number of chunks that can be reconstructed from partial data into the original object. This is more space efficient than replication on larger objects, but it adds latency and is more computationally intensive. The overhead of erasure coding makes it space inefficient for smaller objects, and block storage requires a replicated cache tier to utilize it. As such, erasure coding is recommended for capacity efficiency, whereas replication is most appropriate for lower capacity block storage and small objects.   Putting data on hardware   One of the key differentiating factors between different object storage systems is the method used to determine where data is placed on hardware. Ceph calculates data locations using a deterministic algorithm called Controlled Replication Under Scalable Hashing (CRUSH). CRUSH uses a set of configurable rules and placement groups (PGs) in this calculation. Placement groups tell data where it is allowed to be stored and are architected in such a way that data will be resilient to hardware failure.   HPE value for a Ceph storage environment   Hewlett Packard Enterprise (HPE) and SUSE have partnered to deliver the benefits of SDS on reliable hardware. SUSE Enterprise Storage™ on HPE ProLiant DL and Apollo servers can simplify management of today’s volume of data— and provide the time to value, cost control and flexibility to scale for all of your enterprise storage needs. HPE hardware gives you the flexibility to choose the configuration building blocks that are right for your business needs. The HPE Apollo 4000 Gen10 server systems are most suited for the task and allow you to find the right balance between performance, cost-per-gigabyte, building block size, and failure domain size.   Introduction   Software defined storage running on Linux servers can be deployed on a variety of hardware platforms. However, clusters built on a white-box server infrastructure work for business at small scale, but as they grow, the complexity and cost make them less compelling than enterprise hardware-based solutions. With white-box server infrastructure, IT has to standardize and integrate platforms as well as supported components themselves, and support escalation becomes more complicated. Without standardized toolsets to manage the hardware at scale, IT must chart their own way with platform management and automation. Often the result is the IT staff working harder and the businesses spending more to support a white-box hardware infrastructure than the one-time CAPEX savings realized in buying the white-box servers. Using an HPE hardware and software solution provides advantages that reduce OPEX spending not available in an infrastructure built on white-box servers. Key OPEX savings from using an integrated HPE solution are: Platform management tools that scale across data centers Server components and form factors that are optimized for enterprise use cases Hardware platforms where component parts have been qualified together A proven, worldwide hardware support infrastructure   Disk encryption   In addition to the benefits above, all Apollo 4000 configurations include an HPE Smart Array card capable of secure encryption where enterprise-class encryption is needed. Encryption is FIPS-2—certified for security, has been tested as not affecting IOPS on spinning media for low-performance impact, and is transparent to the operating system for ease-of-use. This means any drive supported on the server can be used, giving much more cost/performance flexibility than encryption on drive solutions. Key management is simple and can be managed locally or via an enterprise key management system. hpe.com/servers/secureencryption   Multi-generational Ceph support   Ceph cluster support mixing multiple generations of x86 server storage nodes. Apollo 4510 Gen10 can be used to expand existing storage cluster based on Apollo Gen9 systems.   BVMS and Software Defined Video Surveillance Storage   Introduction   Video surveillance cameras generate more data as a result of higher resolutions and frame-rates. This has a direct impact on the storage costs of the entire video surveillance environment. The storage consumption can be reduced to use alarm recording instead of continuous recording. This means the system will only start the recording when an alarm is generated (for example, when motion is detected). However, in some projects continuous recording is still required. This entire concept is described in a separate whitepaper: BVMS - Policy Based Recording   Video Recording Manager   The Bosch Video Recording Manager (VRM) is at the heart of the recording system. Instead of acting like an NVR (which takes video streams from the cameras and stores it on a storage environment) it just tells the Bosch cameras where to record their video. This means that the VRM is not involved in the recording itself, which has a couple of benefits. The first benefit relates to performance: one VRM is able to manage the recording for as much as 2000 cameras an 2 petabyte of storage, while a typical NVR struggles to handle 300 cameras. One BVMS system can handle up to 128 VRMs, which results in a maximum of 256 petabyte per BVMS system. The second benefit relates to resilience: if the VRM fails, the cameras continue to record for a configurable amount of time. Depending on that configuration, the VRM ensures the cameras have a list of potential storage locations (or block) cached. The camera itself checks the availability of the location and, if a storage location is unavailable or goes off-line unexpectedly, it will automatically fail-over to the next location on the list. The camera even has a built-in cache which stores the last couple of seconds of video. This cache is flushed to the next storage location when a fail-over occurs, which results in a zero frame-loss fail-over. When the VRM fails, the camera offers as a fail-over replay path. Optionally a fail-over VRM can be added to the environment. The third benefit relates to scalability: the VRM creates virtual blocks on the storage locations, which are reserved for a specific camera (depending on the configured retention time and failure options). If storage capacity is added to the system, the VRM re-calculates the available storage space and distributes the new virtual blocks to the cameras which are active in the system.   Test details   System configuration   Hardware     Software   Available on request at HPE, SUSE or Bosch.   Process   Describe test process.   Results   Recording     Record and replay     Link loss   The iSCSI gateway is disconnected from the network. The camera re-connect time (time it takes before recording is restarted) will be measured.   Record, replay and rebuild   Disk is removed from the system   Node loss   One OSD node is disconnected from the system. ... View more

Question   Does BVMS meet the requirements specified in IEC62676-1?   Answer   The attached document describes how a BVMS system meets the requirements specified by IEC62676-1. ... View more

Question   How can I combine an ISS SecureOS Auto system (providing ANPR functionality) with a BVMS system?   Answer     Functionality   SecureOS sends events from analytics to BVMS, which can be translated into alarms and/or stored into the logbook.   Events received   Event Included metadata Description License Plate Detected License plate, Direction, DirectionID, SourceID General License plate event License Plate on watchlist detected License plate, Direction, DirectionID, SourceID Watchlist License plate event     Installation   ISS SecureOS   Install the BVMS SDK   The BVMS SDK needs to be installed on the ISS SecureOS system, if it is not running on the same server as the BVMS Management Server. The BVMS SDK can be installed as part of the BVMS installation package.   The integration between ISS SecureOS and BVMS is based on Javascript technology. To enable the use of the Javascript plugin a DLL file needs to be registration. Copy Bosch.Vms.VirtualInputsServer.dll from the BVMS Management Server C:\Program Files\Bosch\VMS\bin() to the ISS SecureOS server (C:\Program Files\Bosch\VMS\bin) Register the DLL by calling from the root of the .NET framework directory: regasm.exe /codebase “C:\Program Files\Bosch\VMS\bin\Bosch.Vms.VirtualInputsServer.dll“     Sending events   Open the ISS configuration from the Windows task bar.   Browse to the VB/JScript programs node. Sending events for all detected license plates and trigger alarm on watchlist events Create a new JScript program and use the code-example below. Adjust the necessary parameters, for example the IP address, username and password of the BVMS server.   var BVMS_server = "192.168.178.81:5390"; // IP-address and port of BVMS var BVMS_login = "Admin"; // BVMS username var BVMS_password = "xyz"; // BVMS username password var pass function Init() { // Execute function LPPass when a license plate is detected for all cameras Core.RegisterEventHandler("LPR_CAM","*","CAR_LP_RECOGNIZED","Detection"); // Execute function Watchlist when a license plate on a watchlist is detected Core.RegisterEventHandler("LPR_LOGIC","*","CAR_LP_FOUND","Watchlist"); } function Detection(event) { // Store license plate event in global variable pass pass = event // Send data to BVMS Logbook var VirtInput; // BVMS VirtualInputID for Logbook is equal to the ISS SecureOS Camera ID var inputNr = event.sourceid; var alarmId = 1; var dataString1 = ""; var dataString2 = event.number; // License plate var dataString3 = event.direction_id; // Direction ID var dataString4 = event.direction_name; // Direction Name var dataString5 = event.sourceid; // ISS SecureOS Camera Source ID var dataString6 = ""; // reserved var dataString7 = ""; // reserved var dataString8 = ""; // reserved var dataString9 = ""; // reserved var dataString10 = ""; // reserved Log.Debug("Detection", inputNr, dataString1, dataString2, dataString3, dataString4, dataString5, dataString6, dataString7, dataString8, dataString9, dataString10, alarmId); VirtInput = new ActiveXObject("Bosch.Vms.VirtualInputsServer"); VirtInput.Connect(BVMS_server, BVMS_login, BVMS_password); VirtInput.SendData(inputNr, dataString1, dataString2, dataString3, dataString4, dataString5, dataString6, dataString7, dataString8, dataString9, dataString10, alarmId); } function Watchlist(event) { var VirtInput; // BVMS VirtualInputID for Logbook is equal to the ISS SecureOS Camera ID + 1000 var inputNr = (parseInt(event.sourceid) + 1000).toString(); var alarmId = 1; var dataString1 = ""; var dataString2 = event.number; // License plate var dataString3 = event.direction_id; // Direction ID var dataString4 = event.direction_name; // Direction name var dataString5 = event.sourceid; // ISS SecureOS Camera Source ID var dataString6 = event.database_type; // Watchlist type var dataString7 = event.database_name; // Watchlist name var dataString8 = ""; // reserved var dataString9 = ""; // reserved var dataString10 = ""; // reserved Log.Debug("Watchlist", inputNr, dataString1, dataString2, dataString3, dataString4, dataString5, dataString6, dataString7, dataString8, dataString9, dataString10, alarmId); VirtInput = new ActiveXObject("Bosch.Vms.VirtualInputsServer"); VirtInput.Connect(BVMS_server, BVMS_login, BVMS_password); VirtInput.SendData(inputNr, dataString1, dataString2, dataString3, dataString4, dataString5, dataString6, dataString7, dataString8, dataString9, dataString10, alarmId); }   The script is based on one single Watchlist, but can be extended to multiple Watchlists as well. Configuring ISS SecureOS Watchlists   The Watchlists in ISS SercureOS are not enabled by default. The ISS SecureOS Auto user guide describes how to enable the Watchlists (section 4.1.5.2 Watchlists and 5.1.5.2.1 External Database Connection Example).   BVMS - Configuration   Creating virtual inputs   Create the necessary virtual inputs in the BVMS device tree. In the example below two virtual inputs are used and named after two cameras for which ISS SecurOS is providing ANPR.   Add the virtual inputs to the logical tree. It is recommended to add, per ANPR camera, one virtual input which receives all ANPR events and one virtual input which only receives and event when a watchlist is triggered.   Trigger alarms (if necessary) for the related virtual inputs. The virtual input used for receiving all ANPR events will not be configured to raise an alarm. The virtual input which receives the watchlist events will be configured to raise an alarm.   Creating alarms   Configure the appropriate alarm settings (alarm settings are described in the BVMS Configuration Manual).   Instant-playback can be used to allow the operator to immediately verify the incident as it is happening.   Operation   Detecting incidents   When the watchlist is configured the BVMS alarms are visualized using the BVMS alarm management mechanism. The license plate itself is showed and stored as Text Data.   Investigation   The logbook search or search video by event mechanism can be used to search for a specific license plate. License plates are stored as "Data 2". The picture below shows an example of the search parameters.   ... View more

Question   Can I move the BVMS Logbook database to a separate Microsoft SQL Server to ease maintenance or increase the size of the Logbook?   Answer   BVMS is using Microsoft SQL Server Express to store its logbook. Based on the information provided by Microsoft (Compare SQL Server 2017 editions), SQL Server Express is limited to a 10GB database size. This could be insufficient for larger installations or installations that require a very long logbook retention time. Additionally, some organizations have a dedicated SQL server environment which should be utilized by all applications. The BVMS Logbook database can be moved to another SQL Server. This guide describes the steps that are necessary to migrate the database and describes how to confirm if the migration was successful.   Knowledge This guide assumes the new database server is installed and up and running. Bosch strongly recommends that an experienced database administrator executes the migration. Experience with Microsoft SQL Server Management Studio is required. This guide does not include troubleshooting of the migration process (it is expected the database administrator is able to handle this) nor does it include any performance optimizations of the SQL server. This guide assumes the SQL server "sa" (Server Administrator) account is available for administrative purposes on the used SQL server. Support The migration process itself is not supported by the Bosch technical support teams. Once the database is migrated, the technical support teams will provide support. An experienced database administrator should be able to assist the technical support team in case the system experiences issues related to the logbook.   Version This guide is based on Microsoft Windows Server 2016 (fully updated on 2018-09-28) and Microsoft SQL Server 2017 (version 14.0.2002.14). The SQL Server should be installed in "Mixed mode" authentication (having an "sa" account) and this guide assumes an instance name "BVMS_External".   1. Preparing the SQL server In the first step, the new SQL server is prepared for remote connections. This section assumes the SQL server has just been installed and the configuration is fresh. The instance name used in this guide is "MSSQLSERVER".   2. SQL server settings The SQL server can be configured using the SQL Server configuration manager, which can be started using the Windows start menu. In this step, the TCP/IP protocol will be enabled for the network adapter which will be used to communicate with the BVMS management server. Browse to the SQL Server Network Configuration, Protocols for MSSQLSERVER. Open the properties window of the TCP/IP protocol. Go to the IP Addresses tab in the properties window, and find the network adapter (search for the correct IP address) which should be used for communication with the BVMS management server. Enable the SQL Service on this adapter by changing the Enabled option to Yes.   Restart the SQL Server (MSSQLSERVER) in order to apply the changes.   3. Firewall settings In order to allow the SQL Server to communicate with the BVMS management server, the firewall needs to be adjusted. Open the Windows Firewall with Advanced Security and create a new firewall rule, as shown in the image below. Create a new inbound rule for ports. The SQL Server communicates based on TCP port 1433. Fill in the form as shown in the image below. Move through the action (grant access) step and apply the rule for all firewall profiles (private, public, domain). Give the firewall rule an appropriate name. In order to increase the security level, the rule can be adjusted in order to only allow communication between the SQL Server and the BVMS Management server. Open the properties dialogue of the firewall rule, go to the Scope tab, and add the remote IP address of the BVMS Management server (the example below shows 192.168.20.151 as the BVMS Management server IP address. In order to test the rule, the Microsoft SQL Server Management Studio should be able to login to the SQL server from the BVMS Management server using the "sa" account.   4. Moving data   Now that the SQL server has been prepared, the logbook database will be moved from the BVMS Management server to the SQL Server.   4.1. Stop BVMS SQL server instance Open the SQL Server Configuration Manager on the BVMS Management server and Stop the SQL Server (BVMS) process.   4.2 Moving data The logbook database is located in C:\ProgramData\Bosch\VMS\DB on the BVMS Management server. Copy the BVMSLogbook.mdf and BVMSLogbook.ldf (using a USB stick or using the network) to the SQL server. The files should be copied to the  C:\Program Files\Microsoft SQL Server\MSSQL.14.BVMS_External\MSSQL\DATA folder. This folder location has the right permissions for the SQL Server to adjust these files. If another location is chosen, the database administrator needs to ensure the SQL server has the correct rights   4.3 Attaching database After the database files have been moved, they need to be attached to the SQL Server process. Login to the SQL Server using Microsoft SQL Server Management Studio on the BVMS Management server. Right click the Database folder and Attach a new database to the SQL Server. Browse to the C:\Program Files\Microsoft SQL Server\MSSQL.14.BVMS_External\MSSQL\DATA and select the BVMSLogbook database file. The database should be attached to the SQL Server and it should appear in the tree.   4.4 Set the database size By default, the size of the BVMS logbook has been fixed to 4GB. To allow the logbook to grow, the size of the database needs to be changed. Right click the BVMSLogbook database in the SQL Server Management Studio and click properties. Go to the Files page and change the Initial Size of the data and log files as required. Microsoft Support pages   4.5 Confirming data migration In order to confirm the data migration, the content of the database can be checked by executing a SELECT query on the data. Expand the BVMSLogbook database, go into the Tables folder, right click on the dbo.Devices and click on "Select Top 1000 Rows". The result should show devices recognized from the BVMS configuration, as shown below.   5. SQL Server security   It is not recommended to use the "sa" account for BVMS to login to the SQL Server. In this section a separate SQL Server user account will be created.   5.1. Create user Browse to the Security - Login folder using the Microsoft SQL Server Management Studio. Create a new login as shown in the image below. Fill the form with an appropriate user-name and password, deselect Enforce password expiration (in order to prevent the BVMS Management server to lose access once the password has expired) and select the default database (BVMSLogbook). Go to the User Mapping tab, map the user to the BVMSLogbook database and enrol the user as db_datareader, db_datawriter and db_owner to the database.   Finish by clicking OK.   5.2 Verify user Logout of the Microsoft SQL Server Management Studio. Login using the newly created user and verify if the user has access to the database. The result should show devices recognized from the BVMS configuration, as shown below.   6. BVMS settings   Now that the database is configured and the access is tested, BVMS needs to be re-directed to the new location of the logbook database.   6.1 Change SQL connection string The SQL Connection string can be configured in the Options dialogue. Change the SQL Server connection string based on the format and example below Data Source=YourDBServerAddress;Initial Catalog=DatabaseName;Persist Security Info=True;User ID=YourUserID;Password=YourPassword Data Source=192.168.20.161;Initial Catalog=BVMSLogbook;Persist Security Info=True;User ID=BVMS;Password=Bosch123   Restart the BVMS Management server after the configuration has been saved and activated.   6.2 Verify logbook connectivity The last step is to verify the logbook migration in the BVMS Operator Client. Open the logbook search window, as shown in the image below. When the migration has succeeded, the logbook should contain a historical overview of events, dated from before the migration of the database.   7. Upgrading BVMS Do not de-install SQL Server Express from the BVMS Management Server. This might cause the BVMS set-up to fail, when it used to upgrade the Management Server. The SQL Server Express services might be stopped during normal operations, but need to be started and running during the upgrade.   When a new BVMS release is created changed to the database schema might have been made. Normally, when using the embedded SQL Server, the database scheme is automatically upgraded . As the database is moved to a different server, the set-up mechanism cannot realize an upgrade of the schema of the remote database. To allow system administrators to upgrade the database schema manually, the DbLogBookMigrator has been created. This tool can be found in the C:\Program Files\Bosch\VMS\bin directory (DBLogbookMigrator.exe). Start the tool, enter the SQL Server connection string (as entered in section 4.1) and start the migration process. The progress log will show an indication of the result.   8. SQL running on a different HDD than default one (C:)    By default, BVMS installs both SQL Server and the SQL instance "BVMS" on the main OS drive (typically - C:\). Currently, there's no option available to change this setting during the installation.   In some cases it might be preferred to have all the SQL Server files installed on a hard drive different than C:. This chapter provides step-by-step procedure to achieve this goal.   8.1. Install the SQL Server separately (before the BVMS setup is started)   When installed SQL Server using a separate setup, it is possible to define the specific folder where SQL Server files will be stored. Run the setup and define the target location where SQL Server files should be installed. Install an empty SQL instance called "BVMS". In order to guarantee compatibility, please use the same MS SQL Server version as used by your target BVMS version. (please refer to the corresponding BVMS Release Notes)   8.2. Run the BVMS installation   Once the SQL instance is installed, start the BVMS installation using the standard setup files. If BVMS setup detects the existing SQL instance BVMS, it will automatically use it instead of installing the new instance. During the BVMS setup, existing SQL instance will be used and database schema will be applied. However, DB files will be stored at the default location of C:\ProgramData\Bosch\VMS\DB. In order to completely move SQL files from the C: drive, database files shall be moved in the next step.   8.3. Move the database files   Please follow the same steps as described in the chapter 4. Moving data of this document. Instead of moving the DB files to a separate machine, store them on the target hard drive of the server.   9. Troubleshooting   If the migration has failed the BVMS Operator Client will report it is not able to access the database. This could have several root-causes. The connectivity between the SQL Server and BVMS Management server can be tested using general network troubleshooting tools, like ping (take care of the firewall configuration!). Additionally the firewall can be temporarily disabled to verify if it has been configured correctly. The Microsoft SQL Server Management Studio should be able to login from the BVMS Management server to the SQL Server. Last, the user account which has been created should have the correct roles on the database. ... View more