In many cases a minimum and maximum retention time needs to be defined in a video surveillance systems due to legal requirements. While the minimum retention time defines the time period for how long video recordings need to be stored, the maximum retention time defines after which period of time the recordings have to be deleted. Thus, the minimum retention time is going to influence the amount of storage needed. The higher the minimum retention time the more storage space is required.
Hence, the storage space needs to be large enough to store the recordings for the minimum retention. For the maximum retention time this doesn’t have to be the case. Still users might be confused why recordings gaps might appear sort-of randomly, if the system does not have enough storage space to keep all recordings until the maximum retention time is reached. To understand what is going on we have to remember the principle of the VRM block assignment first.
For each camera in the system the BOSCH Video Recording Manager (VRM) generates a list of recording blocks (LUNs) on which the camera can next record. Therefore, the VRM makes an estimation based on the data rate and the amount of data of each camera in the system (global optimization). Basically, the VRM predicts when which camera needs a new block and always lists the block which will be the oldest block at the time the camera needs to record on the next block. One could think of it as a “next oldest block” estimation done by the VRM. But the prediction of the VRM might differ from the reality (mainly because of variance in recording bitrate) and this can cause recording gaps if the storage space is not large enough to support the maximum retention time.
Let’s have a closer look on the following two cases:
Sufficient storage space for maximum retention time
Insufficient storage space for maximum retention time
Sufficient storage space for maximum retention time
In case of sufficient storage space to fulfill the maximum retention time for every camera in the system no random recording gaps will appear, because the VRM will always assign a block containing recordings, which are older than the maximum retention time. Thus, for each camera the recording blocks will be kept until the maximum retention time is reached as illustrated in Figure 1.
Figure 1: Enough storage space to cover the maximum retention time for each camera of the system
Insufficient storage space for maximum retention time
In case the system is designed such that the storage space is not large enough to store all recordings from all cameras until the maximum retention time is reached, the VRM will of course still do its estimation and predict the oldest recording block when a camera will ask for a new block. Assuming an ideal setup (with ideal network connection where each camera has the same data rate and all cameras record the same amount of video data simultaneously), the oldest block would always be assigned by the VRM. Hence, no recordings gaps should appear for recordings older than the minimum retention time, compare Figure 2. This is was most customers falsely assume or expect.
Figure 2: Customer expectation of the system behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
However, in reality the stated assumptions do not apply. Network connection, data rate, amount of recorded video data, etc. varies. Thus, the “next oldest block” estimation of the VRM can differ from reality. Since each camera already got its block list from the VRM and records according to this block list, it can happen that not the truly oldest block is used and recording gaps appear as shown in Figure 3.
Figure 3: System behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
How to avoid or minimize this effect
To avoid this effect of random recording gaps simply add enough storage to your system. To get the best out of your system in terms of storage usage, the optimum would be to set the maximum retention time to storage limit, see Figure 4, but that is almost impossible to realize in practice.
Figure 4: In principle a maximum retention time set to the storage limit would avoid random recording gaps
Option 1 to minimize the effect in practice is to estimate the maximum retention time so that it will not exceed the storage limit of the system as illustrated in Figure 5.
Figure 5: Maximum retention very close to the storage limit will minimize the random recording gaps
Another less recommended option is to set a smaller time difference between the minimum and maximum retention time. But especially when the minimum retention time is shifted closer to the maximum retention time that introduces the risk that the VRM cannot free up storage space in case the minimum retention time is reached, which might result in a recording stop. Thus, we recommend to go for the first option.
One last hint: Changing the retention time on a running system is not going to influence the retention time of already recorded blocks. but will of cousre only be applied to new recorded video footage. Hence, changing the retention time is no option for an immediate change of required storage.
Compared to hardware, in which it is relatively easy to define an end-of-support concept based on the expected lifetime, software behaves totally different. In theory, when the environment does not change, software can still be running ten years after it has been installed. As new versions of the software are released regularly, it is important for customers to know what they can expect from Bosch Building Technologies when the software is purchased. This document describes how Bosch Building Technologies handles the life-cycle of the BVMS, BIS, AMS, and APE, and in which state a specific release can reside. Additionally this document lists the up-to-date situation for all of those software packages.
The attached documents should help you to make the upgrade process as smooth as possible. The upgrade itself is not restricted to BVMS software only. The supported software and firmware versions can be found in the release notes of the related BVMS version.
An attachment is added to this article for each BVMS version. Currently the upgrade guides for BVMS 8.0 and 9.0 are attached to this article. From BVMS 10.0 onwards a description on how to migrate systems has been included as well.
The attached document describes the settings you must perform after having installed BIS and BVMS on the different computers. Ensure that the installations of BIS Server and BVMS Management Server were performed successfully on separate computers. Additionally you must have purchased and activated an OPC Server License for BVMS.
The document can be found in the attachments section on the bottom of the page or the right side of the page. Please look for the attachment icon.
What's new in version 1.3.1?
Dear users, thank you for working with the Bosch Project Assistant. Based on your feedback, we have introduced the following improvements and features to make its use even more effective and enjoyable: • Sorting option on project overview page • Easier and faster removal of cameras from a project • Time server support • Re-commissioning support for VRM-managed cameras (focus on Flexidome IP 8000i) • Configuration mismatch (between project/app and camera) resolution dialog • Integration of Bosch Portable camera installation tool (NPD-3001-WAP), i.e. automatic detection of its wireless access point, management of multiple tools, and configuration of the tool’s network settings within the app
Please check out the updated article " How-to: connect to and configure the portable camera installation tool ". Here we have added new videos that help you to get started and which explain the sepcifics of the different platforms - iOS, Android and Windows.
Your Bosch Security App Team
PS: For details, please have a look at the latest release letter in our Bosch Security Download Area.
The attached document 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 document describes how data, as processed during the Person Identification steps, can be classified. Finally, this document lists technical measures for data protection in the context of BVMS Person Identification.
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.
The full description can be found in the attached whitepaper.
How can I combine a ISS SecureOS Auto system (providing ANPR functionality) with a BVMS system?
The attached document describes the steps how to configure BVMS and the ISS SecureOS Auto system for achieving watchlist ANPR alarms and recorded ANPR detections into the BVMS logbook.
BVMS Lite is a BVMS edition which can be downloaded and activated free-of-charge. How can I set-up a basic (live and recorded video) BVMS Lite system?
First, you need to download the software package, active the BVMS Lite license and install the software. This is described in this article: BVMS - Activating a license.
Second, you need to prepare an iSCSI environment which is suitable for recording video. Any Windows Server based operating system will do. This is described in this article: BVMS - Configuring a Microsoft iSCSI target.
Last, you need to add cameras to the system and start the recording. This is described in this youtube video: How to add a new camera using Configuration Client (BVMS).
Now, have a look at the Operator Client quick guide and you're ready to go!
Where can I get more information on advanced functionality?
Once the software (configuration client or operator client) is running you can press F1 at any time to open the embedded software help! All of the advanced functionality BVMS offers is explained in the help files.
Microsoft Event Logging, when an error occurs, the system administrator or Integrator must determine what caused the error. The operator can then use the event log to help determine what conditions caused the error and identify the context in which it occurred.
Starting Event Viewer
The procedure for starting Event Viewer depends on your starting point, e.g. windows key + R type in ”eventvwr.msc” hit enter.
With the decent administrative access, you can select any computer in your network to view that Microsoft system event logs.
To select computers in Event Viewer:
In the top of the console tree, right-click Event Viewer (local), and then click Connect to another computer.
Enter FQDN/NetBIOS name or browser to the regarding machine
Adjusting Event Viewer Settings
In the console tree, right-click the appropriate log file, and then click Properties. Click the General tab.
Saving Event Logs
In the console tree, right-click the appropriate log file, and then click Save Log File As. Navigate to the subfolder in which you want to save the file, type a name for the file, click the file type, and then click Save.
Clearing Event Logs
In the console tree, right-click the appropriate log file, and then click clear all Events. You are prompted for whether you want to save the log to a file before clearing it. Click “Yes” to save a log and clear all events. If you click No, the log is not saved, but all events are cleared from the selected Event log. If you click Cancel, the request to clear the log is canceled.
Viewing Event Details
In the console tree, right-click the appropriate log file. A list of events in the log file is displayed in the details pane of Event Viewer. Click a specific event in the details pane to display the Event Properties dialog box and details about the event.
In the console tree, right-click the appropriate log file, and then click Properties. Click the Filter tab. Type the appropriate information that you would like to filter.
In the console tree, right-click the appropriate log file. On the View menu, click Find. Type the appropriate information that you would like to find in the dialog box, and then click Find Next.
An event that indicates a significant problem such as loss of data or loss of functionality. For example, if a service fails to load during startup, an Error event is logged.
An event that is not necessarily significant, but may indicate a possible future problem. For example, when disk space is low, a Warning event is logged. If an application can recover from an event without loss of functionality or data, it can generally classify the event as a Warning event.
An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, it may be appropriate to log an Information event. Note that it is generally inappropriate for a desktop application to log an event each time it starts.
An event that records an audited security access attempt that is successful. For example, a user's successful attempt to log on to the system is logged as a Success Audit event.
An event that records an audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt is logged as a Failure Audit event.
The events themselves are what we’re trying to see, of course, and their usefulness can range from really specific and obvious things that you can fix easily to the totally undefined messages that don’t make any sense and you can’t find any information on your preferred search engine. example:
The regular fields on the display contain:
Log Name – while in older versions of Windows everything got dumped into the Application or System log, in the more modern editions there are dozens or hundreds of different logs to choose from. Each Windows component will most likely have its own log.
Source – this is the name of the software that generates the log event. The name usually doesn’t directly match with a filename, of course, but it is a representation of which component did it.
Event ID – the all-important Event ID can actually be a little confusing. If you were to Google for “event ID 122” that you see in the next screenshot, you wouldn’t end up with very useful information unless you also include the Source, or application name. This is because every application can define their own unique Event IDs.
Level – This tells you how severe the event is – Information just tells you that something has changed or a component has started, or something has completed. Warning tells you that something might be going wrong, but it isn’t all that important yet. Error tells you that something happened that shouldn’t have happened, but isn’t always the end of the world. Critical, on the other hand, means something is broken somewhere, and the component that triggered this event has probably crashed.
User – this field tells you whether it was a system component or your user account that was running the process that caused the error. This can be helpful when looking through things.
OpCode – this field theoretically tells you what activity the application or component was doing when the event was triggered. In practice, however, it will almost always say “Info” and is pretty useless.
Computer – on your home desktop, this will usually just be your PC’s name, but in the IT world, you can actually forward events from one computer or server to another computer. You can also connect Event Viewer to another PC or server.
Task Category – this field is not always used, but it ends up basically being an informational field that tells you a bit more information about the event.
Keywords – this field is not usually used, and generally contains useless information.
As a rule of thumb (common way of doing), you should try searching by the general description, or the Event ID and the source, or a combination of those values. Just remember that the Event ID is unique for each application. So there is a lot of overlap and you can’t just search for “Event ID 122” only. This is because users might find the list is too large and too general, your specific search aspect might not fit your issue.
What's new in version 1.2?
Next to general stability improvements and bug fixes, version 1.2 of the Project Assistant introduces the following new features:
Support of Flexidome IP 8000i Wi-Fi camera with regard to wireless commissioning
.txt file import now supports tags to be somewhere in the column header, e.g. “IP address [ip]”, where for version 1.1 only the [ip] tag was allowed in the column header exclusively
Software sealing support for cameras with firmware 6.60+
Extended report information
Project Assistant project file import functionality in Configuration Manager 6.10
Bosch portable camera installation tool is available and can be used in combination with the Project Assistant (check out the corresponding how-to video in this community)
PS: For detailed information, please refer to the release letter attached.
Combined firmware package 6.60 – applicable to all platforms
The Release Letter of the combined firmware package for all platforms 6.60.1321 provides information about the dependencies between firmware versions for a better understanding of the upgrade process of devices with older firmware.
CCP4 and CPP6 devices:
Due to an internal file system being introduced to CPP4 and CPP6 since firmware 6.10 and architectural changes thereof, a direct upgrade from firmware below version 6.10 to latest firmware is only possible via intermediate firmware 6.1x.
CPP4 cameras with firmware versions below 6.10 need to upload this package twice. For example, when having firmware 5.92 on a CPP4 device, you need to load the CPP all common firmware file two times: > First time this is loaded the device will be updated to the 6.11.0021 which is part of the common file. > Second time you load the common firmware file, the update to 06.50.0128 will be performed.
CPP6 cameras with firmware versions below 6.10 need to upload the separate firmware version 6.1x first to receive the latest firmware version. This means that intermediate firmware version 6.1x for CPP6 needs to be requested from your technical support. A support ticket to Level 3 team at MKP PRM group via the support ticket system is needed. In case we see a high demand for that a new combined firmware file might be created by PRM. Only after receiving and uploading firmware 6.1x, you can upload combined firmware package for all platforms 6.50.0620 or CPP6 specific firmware 6.50.0128.
This combined firmware cannot be applied to CPP5 products with firmware version older than 5.91. It is required to upgrade to intermediate firmware 5.91 first
This means that intermediate firmware version 5.91 for CPP5 needs to be requested from your technical support. Only after receiving and uploading firmware 5.91, you can upload combined firmware package for all platforms e.g. 6.50.0620 or CPP5 specific firmware 6.30.0059. To find a combined firmware file in the downloadstore you can use the folowing URL syntax: https://downloadstore.boschsecurity.com/index.php?type=fw&filter=CPP
or you use the CPP 6.50 combined file here: https://downloadstore.boschsecurity.com/FILES/KnowledgeBase/CPP_FW_6.50.0620.fw
and Releaseletter of that combined firmware package: https://downloadstore.boschsecurity.com/FILES/KnowledgeBase/Bosch_Releaseletter_CPP_FW_6.50.0620.pdf
Note: Upgrading from versions lower than 5.5x
To upgrade to a newer firmware version using this combined firmware package, firmware versions before 5.5x require an intermediate update cycle using the respective platform firmware version mentioned above.
This firmware and its included platform firmware builds are not applicable to MPEG-4 products.
The final firmware version for VIP-X1600-XFM4 modules is FW 5.53. No newer firmware will be provided for these modules.
Configuration Manager cannot upload this Combined Firmware file to VIP-X1600-XFM4 modules. Use the module’s web page instead for uploading; or use the separate firmware file.
The final firmware version for CPP3 devices is FW 5.74. No newer firmware will be provided for these products.
The Combined Firmware file does not load onto VG4 AUTODOME or AUTODOME Easy II via the browser when running a firmware version before 5.52.0017. The specific platform file should be used instead.
(Note: In case any link might not work to the current DownloadStore, see attached a copy PDF of the Release Letter.)
How to get and request a BOSCH Legacy Firmware:
The procedure to request and get an legacy firmware that is no longer online in the web is as follows:
Customers are kindly requested to reach out to the local BOSCH Support (L1 and L2 team).
Bosch Level 2 will ask for the exact BOSCH Commercial Type Number (CTN). The local BOSCH team can check the Global End of service date. The project background (How many of these devices/cameras) need to be collected.
The relevant BOSCH Technical Support (e.g. Level 2) can explain and check if there is the chance to update the project and included management software in order to be able to use the latest BOSCH device firmware as the goal is to have a non-vulnerable product in productive environments.
In case there is no newer firmware available (hardware was discontinued), a commercial hardware upsell can be recommended.
In general all firmware that is not available on the product catalog, and for all firmware files that are ranked to have vulnerabilities, this need to be documented in a Technical Support case.
In case legacy firmware is anyhow needed and requested by our customers, the Bosch Technical support will start an approval flow. The BOSCH Level 3 Technical Support will provide a form/document that must be signed by the installer/endcustomer. See an example PDF (empty) "Example_Aged_Software_Release_form.pdf" attached to this article. Such a form will be prepared by the BOSCH Level 3 Technical support team and provided to our customer/installer in order to confirm that legacy firmware is then used on the risk of the installer and customer (See text and legal note in the PDF). In the future BOSCH plan to introduce and setup a self-service portal for all customers to simplify this process.
The above mentioned combined firmware 6.50 supports:
CPP7.3 HD and UHD cameras update from FW 6.40 or newer to latest FW 6.50
CPP7 UHD cameras update from FW 6.30 or newer to latest FW 6.50
CPP6 UHD cameras update from FW 6.10 or newer to latest FW 6.50
CPP5 encoders update from FW 5.91 or newer to latest FW 6.30
CPP4 HD cameras update from FW < 6.10 to intermediate FW 6.11 update from FW 6.10 or newer to latest FW 6.50
CPP3 cameras and encoders update from FW 4.54.0026 or newer to latest FW 5.74
CPP-ENC VIP-X1600-XFM4 encoders: update from FW 4.2x or newer to latest FW 5.53 VJT XF and VJD-3000 update to latest FW 5.97
The combined firmware package includes the following build versions:
CPP7.3 FW 6.50.0128
CPP7 H.264 6.50.0128
CPP6 H.264 6.50.0128
CPP5 H.264 6.30.0059
CPP4 H.264 6.50.0128
CPP4 H.264 6.11.0021
CPP3 H.264 5.74.0010
CPP-ENC H.264 5.97.0005 for VJT XF family, VJD-3000 and VJC-7000
CPP-ENC H.264 5.53.0004 for VIP X1600 XFM4
For detailed description please refer to the separate release letters.
Customers can upload such combined firmware packages by using multi-select in the Configuration tool "BOSCH Configuration Manager" (currently available in version 06.01.0157 at the BOSCH DownloadStore or Product catalog > Video Software > Video Management Systems > Configuration Manager)
When using the multi-select option in Configuration Manager, please make sure this combined firmware package for all platforms can be uploaded to all the devices selected and there are no additional requirements or intermediate steps needed for any of the devices in question.
This article has status of 31st of October 2018 and changes in this procedure might be introduced. When changes are done, then this article will be updated. Therefore check this article from time to time.
In all VRM installation packages the required .NET framework package is included in the VRM installation routine.
As Microsoft Operating Systems are expected to get and have the latest security updates applied before installing any new software component like VRM (Video Recording Manger) or VSG (Video Streaming Gateway), the installer will successfully finish the installation routine. The same is valid for BOSCH DIVAR IP product range: The DIVAR IP Appliance installer contains Microsoft update packages available from Microsoft at the time BOSCH creates the Appliance installer. But all Microsoft Updates release after the Appliance installer release date are not included in the BOSCH package. It is therefore recommended to check for Microsoft updates whenever a Bosch DIVAR IP Appliance installer is installed.
For VRM (Video Recording Manager) stand-alone Systems and Servers with VSG (Video Streaming Gateway) installed, it is also strongly recommended to check for Microsoft OS updates before the VRM Master Installer is installed/updated.
Note: In case an error code 5100 is shown during the VRM Software installation, please ensure that all Microsoft updates for the used Operating Systems are installed and run the BOSCH Software installer after that once again. For more details Microsoft provides more informaiton here: https://blogs.msdn.microsoft.com/astebner/2008/10/13/net-framework-setup-verification-tool-users-guide/
For older BVMS and VRM installations please also refer to the following previous article: