Displaydata 120-0112 Aura 29 Electronic Label User Manual Manual

ZBD Displays Ltd Aura 29 Electronic Label Manual

Contents

Manual

System Installation Guide for v3.3 Software Release Document Number: 685-0003-08 Date: 21st October 2012 The information disclosed herein is the exclusive property of ZBD Displays Ltd. and is not to be disclosed without the written consent of ZBD Displays Ltd. No part of this publication may be reproduced or transmitted in any form or by any means including electronic storage, reproduction, execution or transmission without the prior written consent of ZBD Displays Ltd. This document is intended for limited circulation. The information contained in this document is subject to change without written notice and should not be construed as a commitment by ZBD Displays Ltd. unless such commitment is expressly given in a covering document. © Copyright ZBD Displays Ltd. (2012)
Strictly Private & Confidential Page 2 of 37 © 2012 ZBD Displays Ltd 685-0003-08 1 Scope This guide is intended to cover the following scenarios.  An initial lab test system.  A Proof of Concept (PoC) in a live store.  A full trial in a live store.  A full roll-out of EPOPS (Electronic Shelf Epops) technology. Project management is a key element of a successful deployment of all the above scenarios. The more time that is spent on creating a defining a project plan the more successful and quickly a system can be deployed. This guide is designed to take users through the essential steps that will allow EPOPS to be deployed effectively within a store environment, ensuring that the system is fully working and that all of the required tools are available to support the installation when it’s live. The solution is designed to be operational as a 24/7 solution which means it is always on and ready. The epops (epops) run in a low power mode when inactive. To facilitate the 24/7 operation it is necessary to ensure that all power saving modes (hibernation/standby etc) are disabled from the Bounce devices. The IT solution usually does backups and price file and image updates overnight. This guide focuses on the Bounce software version 3.3 release and above. The guide references the Bounce ‘Enterprise Interface’ as a means to drive the label system using XML, this is one of ZBD’s preferred methods to build a coherent, working solution. However there are many different methods that can be used to pass data to and from the Bounce system (i.e. OLeDB, direct API, also text based files). If you are creating a system that links to something different or which isn’t referenced in the ZBD documentation then we recommend that you contact the ZBD Support Team support@zbdsolutions.com and discuss the requirements, it is possible that the idea may have already been implemented somewhere else! 2 Change History Date Version Author Changes 24Feb2011 02 PS Updated for v3.0 software release 08Jul2011 03 PS Updated for v3.2 software and Ethernet Communicators 08Feb2012 04 DP Updated to add in Chiller deployment information 30Mar2012 05 DP Updated to reflect v3.3 software release 06Aug2012 06 AP Added Power Saving Mode conditions 13Aug2012 07 GL Added Appendix A – Bounce Manager installation 21Oct2012 08 AP Minor changes to formatting
Strictly Private & Confidential Page 3 of 37 © 2012 ZBD Displays Ltd 685-0003-08 3 Table of Contents 1Scope ___________________________________________________________________ 22Change History ___________________________________________________________ 23Table of Contents __________________________________________________________ 34System Overview __________________________________________________________ 54.1Introduction ________________________________________________________________ 54.2Overview Diagram ___________________________________________________________ 64.3Bounce Architect ____________________________________________________________ 64.4Processor ___________________________________________________________________ 74.5Communicate _______________________________________________________________ 74.6Manager ___________________________________________________________________ 84.7Workflow __________________________________________________________________ 84.8Step 1 – Defining the Template Fields ___________________________________________ 94.9Step 2 – Template Creation ___________________________________________________ 104.10Step 3 – Product Data Acquisition ___________________________________________ 124.11Step 4 – Product Image Rendering ___________________________________________ 124.12Step 5 – Update EPOPS ____________________________________________________ 134.13Step 6 – Report Viewing ____________________________________________________ 135External Documents - Caution ______________________________________________ 136Project Delivery Observations _______________________________________________ 146.1Project Initiation – Project Management – Project Plan ___________________________ 146.2Technical Integration Specification ____________________________________________ 156.3Fixtures and Fittings ________________________________________________________ 166.4Ordering and Shipping ______________________________________________________ 166.5Installation ________________________________________________________________ 166.6Handover __________________________________________________________________ 177Site Survey ______________________________________________________________ 177.1Site Survey basics ___________________________________________________________ 177.2RF Range testing and positioning the communicator ______________________________ 177.2.1RF Range Test tool _______________________________________________________________ 177.2.2RSSI scan ______________________________________________________________________ 177.2.3Smaller format stores (approx. 5000 m2) ______________________________________________ 177.2.4Larger format stores ______________________________________________________________ 177.2.5Environmental considerations ______________________________________________________ 177.2.6Note the position of the IT infrastructure ______________________________________________ 187.3Fixtures and Fittings ________________________________________________________ 197.3.1HL Display and Sitour. ____________________________________________________________ 197.3.2EPOPS ‘Angling’ ________________________________________________________________ 197.3.3Ongoing Staff maintenance ________________________________________________________ 208Training ________________________________________________________________ 20
Strictly Private & Confidential Page 4 of 37 © 2012 ZBD Displays Ltd 685-0003-08 9“Chiller” label deployment _________________________________________________ 2010Communicator Positioning _______________________________________________ 2110.1USB Communicator _______________________________________________________ 2110.2Ethernet Communicator ___________________________________________________ 2110.3Positioning _______________________________________________________________ 2211Software Requirements, Setup and Installation _______________________________ 2211.1Documentation available ___________________________________________________ 2211.2Software Installation – Clean Install __________________________________________ 2311.3Testing __________________________________________________________________ 2412Adding Epops to the Network _____________________________________________ 2412.1Adding epops – step by step _________________________________________________ 2412.2Offsite configuration _______________________________________________________ 2512.3Synchronisation and Label Management ______________________________________ 2512.3.1Synchronisation _________________________________________________________________ 2612.3.2Network Management ____________________________________________________________ 2612.3.3Moving epops between stores/sites __________________________________________________ 2613Product Data Loading ___________________________________________________ 2613.1‘Enterprise’ Interface product data loading ___________________________________ 2713.2Other connection types _____________________________________________________ 2714Linking epops to Products ________________________________________________ 2714.1XML or ‘Enterprise’ interface method _______________________________________ 2814.2ZBD Bounce Manager – Product Assignment __________________________________ 2815Training and Procedures before handover ___________________________________ 2915.1Training _________________________________________________________________ 2915.2Procedures and handover __________________________________________________ 2916System Management ____________________________________________________ 3017Support Overview _______________________________________________________ 3017.1Store level diagnostics______________________________________________________ 3017.1.1Is the RF network working? ________________________________________________________ 3117.1.2What’s the status of the label? ______________________________________________________ 3117.2Partner / Support Level Diagnostics __________________________________________ 3217.2.1Enterprise Interface error logging ____________________________________________________ 3217.2.2Error logs ______________________________________________________________________ 3317.2.3System Management Tools ________________________________________________________ 3317.2.4Other ZBD Software Tools ________________________________________________________ 3418Summary______________________________________________________________ 3519Appendix A – Bounce Manager installation __________________________________ 36
Strictly Private & Confidential Page 5 of 37 © 2012 ZBD Displays Ltd 685-0003-08 4 FCC Warning Statement (related to Epop Displays)  These devices comply with Part 15 of the FCC Rules.  Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) This device must accept any interference received, including interference that may cause undesired operation.  This equipment complies with FCC radiation exposure limits set forth for an uncontrolled environment.  End users must follow the specific operating instructions for satisfying RF exposure compliance.  This transmitter must not be co-located or operating in conjunction with any other antenna or transmitter.  Changes or modifications not expressly approved by the party responsible for compliance could void the user's authority to operate the equipment 5 System Overview An overview of the solution has been included to ensure that all parties involved in planning and implementing the system have a clear understanding of the basics. 5.1 Introduction The EPOPS is ZBD’s electronic point of purchase (epop) display and is designed to replace and/or enhance retailers existing paper ticketing systems and promotional display systems. For an EPOPS system to work effectively the EPOPS must be linked into the retailers product data feeds and the bounce system needs to have access to the feeds that contain any information required to be displayed on an EPOPS. The bounce software suite is designed to provide a number of software modules and tools for defining the integration points between the customer data and the EPOPS. The software enables the development of image templates for simplifying the design of ticketing information and provides tools for defining rules that must be applied to the data feeds in order to ensure that the correct information is displayed on the EPOPS at the right time. The software also provides a network management layer for controlling the update of the EPOPS and recording auditing information that can be retrieved using the reporting module. The software consists of four core elements: Product Description Communicate This product consists of a Microsoft .Net application that runs continuously on a server and is responsible for transmitting the appropriate product images to any EPOPS that have been assigned to the defined products. Communicate is responsible for providing the underlying communications structure for deploying a large number of EPOPS display devices. Processor This product consists of a Microsoft .Net application that runs continuously on a server and uses the Policies and Collections defined within Architect to acquire the data when scheduled, perform the required transformations, determine what data has changed and render product images for those products whose data has changed. Architect This product consists of a Microsoft .Net application that
Strictly Private & Confidential Page 6 of 37 © 2012 ZBD Displays Ltd 685-0003-08 provides the means for a User to define the data sources for their product information, set up what to do with the data and create a schedule of when the data should be examined for changes. Architect also provides tools for defining EPOPS product image templates and for creating Collections of templates that will be used with the defined data set. The Policies and Collections that are created within Architect will then be used by Processor to generate images for the EPOPS displays. Manager This product consists of a web application, written for the Microsoft ASP.Net web application framework, residing on an ASP.Net compatible web server. It provides all the tools required to manage a Bounce software installation via a Web interface. 5.2 Overview Diagram 5.3 Bounce Architect Component Description Policy Architect (Define data sources, transformations & template fields) The Policy component consists of a Windows .Net application for defining the sources of data that will be used in acquiring the product information for the image generation process. Data transformation are also created and edited within Policy Architect. Transformations can be used when the format of the data in the acquired data sources needs to be changed or reformatted to represent what will be rendered in the product image. Any data changes (a trigger) result in new images being generated. Policy Architect provides a means to preview both the acquired data and the EPOPS images that will be created from the data. Any policies that are defined within the Policy Architect
Strictly Private & Confidential Page 7 of 37 © 2012 ZBD Displays Ltd 685-0003-08 application can be saved and imported into Bounce Processor as a configuration file. Template Architect (Define image templates) The Template component consists of a Windows .Net application for defining EPOPS image templates. A template defines the information that should be displayed on an EPOPS. It consists of a set of instructions detailing where and how data fields are rendered within the EPOPS image. Template Architect provides a template Design view alongside a Preview view. This allows the User to be able to see exactly how a product image (or set of product images) will be rendered from the product data set. Template Architect also allows the user to create a Collection of templates. This feature ensures that different templates can be used when rendering the data to handle products that may be on offer, or in a different product category that requires its own style. A Template Collection also includes templates for each of the different EPOPS types e.g. EPOPS 500 and EPOPS 300. Once a User has completed the design of their Template Collection it can then be saved and imported into Bounce Processor as a configuration file. Saved files can also be used by Policy Architect to preview the acquired data. 5.4 Processor Component Description Processor (Acquire/Transform/Render) This component runs as a Service on a Windows OS machine and performs the function of acquiring the data (a ‘trigger’ is a change in the data source) as defined in Architect. It then performs any required transformations and uses the acquired and transformed data to render a product image. For each product in the acquired data set a unique image will be generated using the specific template style defined within the data. Product images are created for each EPOPS type included in the Template Collection e.g. EPOPS500 (epop500), EPOPS300 (epop300). Once an image has been rendered it is then passed to the Communicate component for transmission to the EPOPS. An audit trail is kept of when the data is acquired and when any product images are created and sent to the Communicate component. 5.5 Communicate Component Description Communicate (Transmit, Log) This component also runs as a service on a Windows OS machine and is responsible for managing the transmission of any product images delivered via Acquire/Transform/Render to the appropriate EPOPS units assigned to the product.
Strictly Private & Confidential Page 8 of 37 © 2012 ZBD Displays Ltd 685-0003-08 When Communicate receives a product image update it will check to see if any EPOPS have been assigned to the product and then select the appropriate image for the specific EPOPS type and queue it for transmission e.g. if a product has both an EPOPS 500 and an EPOPS 300 assigned, then Communicate selects the EPOPS 500 image for transmission to the EPOPS 500 and the EPOPS 300 image for transmission to the EPOPS 300. Communicate manages the RF communications layer and will ensure transmissions are re-tried if failures occur due to RF noise etc. An audit trail is kept of all EPOPS communications, retries and failures. 5.6 Manager Component Description Manager (Configuration, Assign, Report) The Configuration component consists of a web application that enables Users to remotely configure and control the Bounce Processor product. Users will be able to stop and start the Processor service and update the Policy rules and Template Collections. The Reports component provides a web based application that enables the User to generate reports detailing when products, EPOPS etc. have been updated. Reports can also be generated of failed transmissions. 5.7 Workflow The following diagram shows an overview of the workflow required to integrate a bounce system into a retail environment. There are 5 steps to complete a full integration. These are: 1. Use Policy Architect to set the data sources and define the Template Fields that will be used in creating the product images. Template Fields are derived either directly from the Product Data Fields in the imported data sources or from transformations on the Product Data Fields. 2. Use Template Architect to create a Collection of image templates for each EPOPS type and for each offer type using the Template Fields defined in step 1
Strictly Private & Confidential Page 9 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Steps 1 & 2 often become an iterative process as the templates are developed. 3. Acquire the Data Values according to the transformation and policy rules defined in steps 1 & 2 4. Render the product images using the Data Values acquired in step 3 and the Template Collection defined in step 2. 5. Use Bounce Manager to view the updated statistics. 5.8 Step 1 – Defining the Template Fields Link Transformation[PromoPrice] = [Price] * 0.8[StockLevel] = If [Stock] > 100 Then “In Stock” Else If [Stock] = 0 Then “Out of Stock” Else “Low Stock”Product Data Fields Template FieldsSKUPricePromoPriceDescriptionBrandModelStockLevelTemplatePolicy RulesPrice DbSKUPriceDescriptionModel DbSKUBrandModelStock DbSKUStock‘Standard’ Template Fields are created using Policy Architect. Definition of the Template Fields begins by determining all the different data sources that will be used to create them and registering these with the Policy Architect application. A data source can take any form and may consist of a simple comma separated value file, an Excel spreadsheet, an XML file, a bitmap image directory, an Access database or more complex transactional databases such as Oracle or Microsoft SQL Server. Once the data sources have been registered the user then defines the data tables and the Product Data Fields that contain the relevant product information to be used in creating the product images. Each of the data source tables registered to Policy Architect needs to be linked to at least one other table to enable Policy Architect to determine how to retrieve the correct Data Values from each of the tables to make a consistent data set. Normally each of the data source tables would be linked via the product ID as this is a unique identifier that would usually be consistent across multiple data sets.
Strictly Private & Confidential Page 10 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Once the user has registered all the data sources and linked the tables they can then concentrate on determining what fields to be retrieved from them in order to define the Template Fields. Obvious fields such as [SKU], [Price], and [Description] etc. can normally be imported without the requirement to perform any transformations on the data as it is acquired. A special Template Field called [Template] must always be defined. This field contains the name of a Template Architect template that will be used by the Bounce Processor when creating the product image. Using Policy Architect the user is able to create new Template Fields by applying transformations to the Product Data Fields e.g. The user can create a new Template Field called [UnitPrice] that is calculated from the data sources by taking the [Price] and dividing it by the [UnitWeight]. Policy Architect is extremely powerful as it allows the user to combine the data source fields in many different ways to create new Template Fields for use by the Bounce Processor during rendering. Conditional fields can be created that enable the renderer to determine whether to show information on the display e.g.  If the word “vegetarian” is found in the [SpecialConsiderations] data source field Policy Architect can create a Template Field called [Vegetarian] and set it to TRUE. Within Template Architect you could then create a template that would act on this Template Field and add the text “Suitable for vegetarians” or place a vegetarian icon on the display if this field is not NULL.  In the example above the [Template] field has been set to ‘Standard’, but a transformation could be applied to one or more of the Product Data Fields to select different templates based on the data in the sources e.g. If [PromoPrice] is non-zero then set the [Template] Product Data Value to ‘Promotional’ else set to ‘Standard’. Once the user has created their initial set of Template Fields it is time to move on to the next step: Template Creation. 5.9 Step 2 – Template Creation
Strictly Private & Confidential Page 11 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Templates are created using a Template Architect. In this stage the user creates a Collection of image templates for each of the EPOPS types and for promotions or special offers etc. A template is a list of instructions for the Bounce Processor renderer detailing what Template Fields, background images and icons to place in an EPOPS image and what attributes, such as font style, to use when rendering the Data Values held by the Template Fields on to the image. Template Architect provides a graphical user interface for defining where and how the Template Fields should be rendered within the product image. Using the GUI the user can select a Template Field and define the area on the EPOPS display that the values contained in the Template Field should be rendered. A selection of field attributes is also available so that the user can apply different fonts, font styles, font sizes etc. The Template Field objects can be inverted to display white on black or the object can be set to auto fit within a bounding rectangle defined by the user. The user can apply conditions to Template Field objects based on the Data Value contained in the field. When a condition is applied the object will only be rendered on the EPOPS display if the condition evaluates True at the time of rendering the image. The user can place Template Fields into a group having its own bounding rectangle and apply group attributes e.g. the user may apply the [Description] and [Ingredients] Template Fields into a group and set the CentredVertical attribute. This would cause the renderer to combine the [Description] and [Ingredients] Data Values into a single object that it would then render around a vertical line central to the group bounding rectangle. Static text objects and basic line drawing objects can also be applied to a template. Users can also import their own background bitmap images into the template providing the ability for creating a consistent graphical look and feel of an EPOPS image. Graphics libraries are also provided for the user to map Template Fields to graphical images that will be rendered in place of the text contained in the field i.e. the user can associate a vegetarian graphic icon to the [Vegetarian] Template Field and the renderer would apply this icon to a specific location for every product where the Data Value is True. The user may end up iterating between this and the previous step during template creation as they may decide to create new Template Fields or make use of different data source fields in the template. Once the user has created a Collection of templates to accommodate the different EPOPS types they can then move on to define the scheduling rules that will be applied to the bounce system.
Strictly Private & Confidential Page 12 of 37 © 2012 ZBD Displays Ltd 685-0003-08 5.10 Step 3 – Product Data Acquisition Product data acquisition is triggered when the data is presented to Bounce. Once the data is presented bounce Processor will use the Product Data Definition rules set up using Policy Architect in step 1 to retrieve the data from the relevant data sources, apply the data transformations and create a local copy of the transformed data. The acquired data is referred to as the Data Values and consists of a table of data with a row for each product. Each row contains data values for each of the Template Fields. The table of Data Values are then used by bounce Processor as the data source for the renderer to create the product images that it will sent to bounce Communicate for transmission to the appropriate EPOPS. Data acquisition can occur completely independent of any of the subsequent steps and is merely the means of creating the data set that can be used within bounce. 5.11 Step 4 – Product Image Rendering Product image rendering occurs within Bounce Processor upon receipt of the data . Bounce Processor will use the Data Values and the Template Collection file to create new product images for each of the products that have changed according to the defined scheduling policies. A new product image will be generated for each of the different EPOPS types supported in the Template Definition File.
Strictly Private & Confidential Page 13 of 37 © 2012 ZBD Displays Ltd 685-0003-08 5.12 Step 5 – Update EPOPS Bounce Communicate queues EPOPS image updates whenever the renderer generates a new product image in Step 4. 1. All newly rendered product images are delivered to Bounce Communicate as soon as they have been created and will commence to transmit the images to the epops Bounce Communicate keeps an audit log of all transaction requests. All updates and their status are logged for future retrieval using Report Manager. 5.13 Step 6 – Report Viewing The Report Manager component of Bounce provides a means for the user to view status and statistical information about the EPOPS system. All actions that are performed by Bounce are logged and reporter provides a means to view those actions in a number of different ways:  The user can get a summary of the last 7 days transactions.  The user can view what updates occurred to a particular product over a specified period of time.  The user can view what updates occurred on a specific date or within a specified time frame. 6 External Documents - Caution References to external documents are made throughout and shown as [Document Class - Reference number (Title)] so for example 530-0027-xx (Batch Configuration Tool). There will also be a version number for each document (-xx). Please check that you have the most recent versions of each document before using it. These documents are likely to change on a regular basis so it is worth checking with ZBD support before beginning a major project that you have the latest versions.
Strictly Private & Confidential Page 14 of 37 © 2012 ZBD Displays Ltd 685-0003-08 7 Project Delivery Observations Delivering a solution and getting it installed can be broken down into a number of phases. Each has its own challenges and some of the major ones are explained here so that the project manager can anticipate them and help manage the customer’s expectations. 7.1 Project Initiation – Project Management – Project Plan You should use the information below to thoroughly plan all the stages of the project. Each new customer will have unique issues which need to be understood and mapped to a new project document. This document provides the basic plan which you can expand to cover all aspects of what will be required to provide a successful solution. The Project Plan should contain all aspects of the Project and allocation of the required time to complete and who is responsible for completing. Key elements will be as follows:-  Initial meeting to assess what is required and also timescales for the complete project and the important when is it required by? Until you have mapped out all the requirements and assessed the time required to achieve them, you will not know if it is possible to achieve a target date.  Define Data feeds from Company  Company to provide current paper label samples  Confirm epop Quantity/Type  Confirm Pilot Store  Provide Store Plan – and internal pictures of store.  Provide an example data file for pilot store  Agree system architecture for Pilot Store  ZBD EPOPS solution training  Host server configured  Delivery of lab demo kit  ZBD solution on site training  Backup solution testing  Label/epop Assignment  Confirm assignment method  Develop label/epop assignment method - Company  Test label assignment  Change Control Approval  Technical Development  Mock up (label/epop layout with all required fields)  Mock up complete  Mirror Mock-up Environment in-house at Partner/ZBD  Test end-to-end integration  Generate Policy/Templates  Sign off Template design  Implementation Planning  Order Epops/epops  Order Shelf Edge Strip/Epops Stands  Details of Pilot Store Work Program  Date of system installation  Confirm data content for F&V product (country of origin?)  RF site survey of Pilot store  RF site survey report  Install Data/Power into Pilot store  Project Leader Holidays (make sure any absence is planned for)
Strictly Private & Confidential Page 15 of 37 © 2012 ZBD Displays Ltd 685-0003-08  Pre-Installation Testing  Deliver qtyxxx epop50 to labo  Configure epops -qtyxxx  "install 'products', template & policy onto lab system"  Lab_Pre-Installation Testing - Mini Pilot  Move labo server +ethernet comm +xxx epop50's to Pilot store  "Deliver~18,000 epops to store"  Installation  PC hardware installed  Install Bounce Software  Test System with live data  Fixtures installed  Shelf Edge Installed  Company Staff Training - store deployment  "Configure epops - ~18,000"  Install Epops/epops and assign to products  Installation complete  Backup solution for trial store - testing  Drop dead date for install  Support Requirements - Pilot setup  Weekly Support Meeting  Support Requirements - Live store  Weekly Support Meeting – 3month Pilot  Weekly KPI assessment A typical Project Plan will look something like the diagram below. 7.2 Technical Integration Specification This should cover the detail needed to build the solution – core data, structure, what are the schema files, folder structures, and processes that the system is going to manage? This document should form the blueprint as to how the system is supposed to function. More importantly this is the specification document that all parties
Strictly Private & Confidential Page 16 of 37 © 2012 ZBD Displays Ltd 685-0003-08 need to agree to before proceeding as the specification needs to be tied down very early in any project. If you do not do this you will be forever changing and developing the solution at your own cost. 7.3 Fixtures and Fittings We must stress the impact that fixtures and fittings can have on the delivery timescale, costs and overall success of any shelf label project. The minimum time we would suggest allowing for delivery of fixtures is 4 weeks if they happen to be readily available from a supplier such as HL. Having custom fixtures designed, tooled and produced could easily stretch into 24 weeks for challenging environments or shapes. Creating a multi-cavity tool that may be needed to press 100K fixtures is also an expensive process. It is also worth stressing that fixtures have a big impact on how the epops look in the store. EPOPS rely on passive light reflection for good readability so not dealing with this issue will have a negative effect on customers and lead to less than positive feedback. 7.4 Ordering and Shipping From a standing start (i.e. without forecasts) the lead-time for components up until finished production units being available is 18 weeks. On this basis it’s very important to place orders and plan the implementation schedule as far in advance as possible. Shipping product by ‘surface’ (ship) rather than by air is our recommended option. Airfreight is very expensive, needs close tracking and must have correct import paperwork and documentation to minimise customs delays. 7.5 Installation Walking into a busy store (or even one that is still being built) to install electronic epops can be a stressful event for staff and the installation team. We recommend completing as many steps as possible off site, in advance before going near the store to make the installation process run smoothly  Is the store/manager aware that you’ll be there?  Do they know what they’re expected to do?  Have Ethernet/power points been installed as requested?  Is someone contactable on the customer side if there’s a data issue? If it looks like everything will be ready and the installation will happen then we also recommend creating a task list for the day which details what needs to happen when and who is responsible for that tasks completion. This will mean everyone should know what they’re doing. No-one wastes time and people can follow a plan, rather than having to keep all the steps in their heads. Following a written task list reduces risks, leads to fewer errors and should avoid needing to make repeat visits to fix issues. Task Notes  RT Test – label area (make sure enough readings are taken) Photograph store (capture any unusual aspects in the store) Photograph fixtures (Capture all types including chillers etc) Check power connectivity (24 hour required, UPS (Uninterruptable Power Supply)
Strictly Private & Confidential Page 17 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Check network access (Switch port available, cabling type) 7.6 Handover Once everything has been installed it is essential to check that all store operatives have received adequate training. Leaving this activity too late may impact any KPI measurements for the project. See section 8 It is possible that store layouts may change after the installation has been completed that could adversely affect the RF characteristics of the system, it is therefore important that the original installation details are retained by the implementation team to allow easier identification of the changes and to propose corrective actions. 8 Site Survey Doing a site survey is absolutely necessary to avoid running into problems when doing the actual installation. This needs to include looking at fixtures and fittings as well as the RF characteristics of the environment to site the communicator properly. 8.1 Site Survey basics Get as much detail about the site in advance.  Site Layout plan (map)  Site Name, full postal address  Contact details of store managers  Attendees Create a plan for the site survey before visiting the site 8.2 RF Range testing and positioning the communicator 8.2.1 RF Range Test tool The RF Range Test tool will be made available to partners – please ask for copies of this from ZBD Support [Document 530-0025] 8.2.2 RSSI scan A document explaining how to do an RSSI scan for conflicting RF noise will be made available to partners – please ask for copies of this from ZBD support [Document 530-0024] 8.2.3 Smaller format stores (approx. 5000 m2) If it’s not a particularly large store or contains less than 7,000 items then one communicator might be enough, unless the store is an unusual shape or has unusual RF characteristics. In all cases an RF range test should still be carried out. 8.2.4 Larger format stores Most shops will require a multiple communicator system and it is mandatory that a full RF survey is conducted to confirm the best placement of communicators to ensure full RF coverage throughout the store and of course this applies to multi-level stores. 8.2.5 Environmental considerations  What departments and product types are going to be labelled?  Proposed location and orientation of the Communicator(s)
Strictly Private & Confidential Page 18 of 37 © 2012 ZBD Displays Ltd 685-0003-08  Ceiling Height, type [demountable, solid concrete, wood, asbestos etc]  Fixture construction/height [steel, wood, 1.2Metres/1.8 Metres etc]  Size/shape of coverage area [Rectangular, L shaped, 48M x 71M etc]  Ceiling infrastructure [traywork/H&V etc] Features such as low ceilings, traywork carrying high power cables, wooden shelves and high metal shelves can have a negative effect on the RF range. Maybe some epops will need a few retries to receive price updates – moving the communicator around to find the optimum position is worth taking time over. To help troubleshoot any technical issues that arise later it’s mandatory to have a map of the store that details the products and departments in each section, this will assist in diagnosing any issues that the store may report post-installation. Department EPOPS50 EPOPS300 EPOPS500 Standard (0-40) Freezer Medicines 350 Y Mens Health 250 Y Nail & Accesories 500 Y Nails 150 Y Oils 200 Y Prepared Meals 400 Y Toys & Gifts 750 500 Y etc. Try to link EPOPS required to map locations 8.2.6 Note the position of the IT infrastructure  Connectivity [Ethernet Category, RF etc]  IP Addressing requirements [allocated IP addresses for Bounce devices]  PC locations [inc new Bounce PC]  Communications Cabinet  Switch/Patch capacity for Bounce devices Make sure the customer’s IT team or contractor is aware if new power or network points need to be installed. Medicines Health Products Nails Oils Prepared Meals Toys
Strictly Private & Confidential Page 19 of 37 © 2012 ZBD Displays Ltd 685-0003-08 8.3 Fixtures and Fittings 8.3.1 HL Display and Sitour. ZBD EPOPS are supported by shelf-edging and other in-store fixings available from several manufacturers, including HL Display and Sitour. Fixing options include:  Standard shelf edging  Shelf edging covers  Bumper strips  Hook item holders  Hanging displays (peg hooks)  Stands (e.g. for Delicatessen)  Clamp fixings Full details of all products available are defined in the ZBD ‘Fixtures & Fittings’ Guide which is available from your ZBD Account Manager. NOTE: lead-time for some fixtures & fittings can be protracted. These requirements should be addressed at the beginning of the project to ensure delivery does not impact the implementation plan. 8.3.2 EPOPS ‘Angling’ ZBD Displays are based on reflective LCD technology. This means that the overall readability of the screens can be affected by their positioning (relative to light sources) within stores. It is most important therefore that the angling of display is set properly for consumers. IMPORTANT NOTE: It is essential that the correct angling of EPOPS is considered in determining shelf-edging, and some other fixtures. Proposed fixings must be tested in-store to confirm acceptability with the client. Spacers to adjust angling, as well as options for ‘reverse angling’ (for high shelves) are also available through ZBD’s Fixtures & Fittings partners. Bottom ledge: 45o(should be protectedby Bumper Bar)Below 1M: 15o Positive1M – 2M: NeutralAbove 2M: 15o NegativeBottom ledge: 45o(should be protectedby Bumper Bar)Below 1M: 15o Positive1M – 2M: NeutralAbove 2M: 15o Negative
Strictly Private & Confidential Page 20 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Whatever system is selected EPOPS must be held firmly by the fixture and this can be done in a number of different ways. 8.3.3 Ongoing Staff maintenance Staff in-store should take responsibility for checking that ticket-edging is in place and correctly positioned. The implementer should ensure that staff have access to replacement fixtures & fittings, as well as access to services should the re-installation of units be required. 9 Training It is very important to ensure all levels of staff are adequately trained in the continued use of an EPOPS system. Store processes and procedures are key to ensuring compliance with local laws on pricing accuracy, labelling information (e.g. country of origin) and general business trading best practises. All partners must train people at the various levels required during the deployment. Remember as a partner you are providing the second level of support and the customer is providing the initial first level of support. Customers must be shown how to maintain an EPOPS system in full functionality. A system Health Check should be performed Daily, Weekly, Monthly. It is important to take action with any issues that are flagged during a Health Check. Failure to do so will mean the system gradual becomes bogged down with issues that have not been addressed in a timely fashion. Any failing epops need to be investigated to ascertain if the epop is in the store (it may have been removed) and will not be communicating. Adequate training might be what determines a successful outcome to any KPI’s that have been defined by the customer. Please ensure you provide adequate training for the solution. 10 “Chiller” label deployment It is very important to understand some basic principles with regard to the deployment of epops (epops) into a “Chiller” environment (temperature controlled fridges that are below 10degC). All epops will usually be configured in a normal ambient room temperature environment (~20degC but could be as high as ~30degC). Once they have been configured onto a system, they can then be placed into a chiller unit. It is extremely important that all the epops (epops) are allowed time to thermally stabilise at the new colder temperature before any image updates are carried out. It is essential to allow 45mins for the epops to reach thermal equilibrium before sending images to the epops. Failure to wait for thermal equilibrium will result in a display which is blackened or smudged, (contains black shadows) and the text/graphics will be hard if not impossible to read. Please note that the same thermal equilibrium time applies to moving a label (epop) from a Chiller into a normal ambient temperature zone.
Strictly Private & Confidential Page 21 of 37 © 2012 ZBD Displays Ltd 685-0003-08 bou nce11 Communicator Positioning Determining the installation positions of Bounce communicator(s) into a site should be carried out by ZBD or approved installers following a full RF survey of the intended site. Documents are available detailing the Site Survey approach for single and multiple Communicator installation:  530-0040-xx (Site Survey Guide)  530-0049-xx (Multi-Communicator RF Survey) ZBD manufacture 2 types of Bounce Communicator:  USB connected Communicator  Ethernet connected Communicator Communicators are not auto-detected by the bounce software. You must use the ‘Communicators’ tab in Bounce Manager to make the system aware of Ethernet communicators or additional USB communicators. These are not plug and play devices. Bounce Software should be loaded before any hardware is added to the system. 11.1 USB Communicator The USB Bounce Communicator is limited to a maximum permitted cable length connection of 5 metres. Note that if a cable longer than 5Metres is used then it will not function correctly and will not be supported by ZBD. In most cases the Communicator would need to be mounted in a central location above the sales floor and would be further than 5metres away from the PC. As such the only practical answer is to use the Ethernet Communicator. The USB communicator is best used as a back office “configure and update” device for ongoing store operations, or for sales demos and support purposes. 11.2 Ethernet Communicator The Ethernet Bounce Communicator is connected directly to the Ethernet network within a site, the device supports Power-over-Ethernet (PoE) or an external power supply. If multiple units are to be deployed it is essential that all devices, including the Bounce PC are all on the same network segment (e.g. 192.168.200.xxx), this will alleviate any network issues. The Ethernet unit is mounted with the aerial in the upward direction.
Strictly Private & Confidential Page 22 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Detail of Ethernet Communicator in bracket 11.3 Positioning The Bounce Communicator should ideally be located in a central position in the area that the epops will be located, ideally the position should be at height of at least 2.5 metres above the floor level and have no metal obstructions within 2 metres to the front, rear and sides. ZBD can provide an off-the-shelf bracket to mount the Communicator in a variety of positions, and also offer extension brackets if required. See diagram below You should make sure that the power can be cycled from the IT room so you do not need a ladder to physically disconnect the Ethernet communicator. This could be a physical mains switch if the Ethernet communicators are powered or the ability to remove the Ethernet PoE cables. The orientation of the Communicator should be as detailed in any Site Survey documentation produced as this could affect coverage in larger sized operations. Bounce Holder Bounce Wall Bracket 12 Software Requirements, Setup and Installation 12.1 Documentation available As part of the overall project management process, the setup of the system should be detailed in the Technical Specification. Due to the greater flexibility available our recommendation is that the solution runs based on the ‘Enterprise Interface’ [550-0009-xx] The Bounce Software suite is available on the ZBD FTP (ftp.zbd.co.uk) site and can be downloaded and installed onto a number of platforms. The Bounce System Software fully supports the following Windows host operating systems.  Windows XP Professional (SP3 or higher) - (32bit)  Windows Vista Business Edition (SP2 or higher) - (32bit)  Windows 7 Professional Edition (SP1 or higher) - (32bit & 64bit)  Windows Server 2003 R2 (SP1 or higher) – (32bit)
Strictly Private & Confidential Page 23 of 37 © 2012 ZBD Displays Ltd 685-0003-08  Windows Server 2008 R2 (SP1 or higher) – (32bit & 64bit) Please remember that the USB communicator only has drivers available for the 32bit versions of these operating systems. We recommend for deployments, whether single or multiple communicators, that Ethernet communicators are used because they are easier to install and support. Installation guides have been produced for each platform and should be referenced prior to any live deployment: 530-0012-xx – Windows Vista & Windows 7 530-0013-xx – Windows Server 2008 Please read the Release Notes for the version of software you are going to be installing. This contains valuable information about a clean install and also upgrading from a prior version. Additional applications for running the USB communicator from a remote machine on the network and other ways to improve the system architecture are available. With a complete Technical Specification we can look at providing tools that may benefit the solution as a whole. Copies of these documents can be requested through ZBD Support support@zbdsolutions.com. If an installation is requested on a platform other than those listed, the request will be submitted to a ZBD Technical review where consideration will be given to the request and business opportunity. 12.2 Software Installation – Clean Install It is important to understand that a clean install is usually the quickest and easiest installation as there will not be any conflicts with any other application software loaded on a used PC system. Regardless of what PC is used the steps below must be followed.  Run the Microsoft Update and download and install all hotfixes, patches and security updates that are available.  Reboot the PC  Run the Microsoft Update (expect to find more updates are now available that were not shown on the last update) and download and install all hotfixes, patches and security updates that are available.  Re-run the Microsoft Update again and ensure no more updates are available.  If this is a used PC, make a backup of the PC. Install Bounce v3.3 software components in the following order:- (Please note you may be requested to reboot the PC, and if so you must do this after each module has completed its installation process.)  Bounce Communicate  Bounce Processor  Bounce Architect  Bounce Manager [please see Appendix A ‘Bounce Manager installation’ for more details]  Run Microsoft Update on the host OS.  Reboot the PC.  Run Microsoft Update again to ensure all patches are applied.
Strictly Private & Confidential Page 24 of 37 © 2012 ZBD Displays Ltd 685-0003-08  Reboot the PC.  Run Bounce Manager and login with username=admin, password=admin  You are now ready to use the Ethernet Discovery Tool and connect the Ethernet Communicator to the system.  Do basic checks to see if the bounce communicator is connected and all epops are attached to the system. 12.3 Testing Before going anywhere near the real store environment we strongly recommend creating a lab system to run tests on the integration, store management and error reporting processes for the pilot. This will help in creating an ‘installation checklist’ that can be sent to the customer’s IT group in advance. This will save a lot of time in-store getting everything up and running so important topics like training and user education can take place. Spending 80% of the time on network and connectivity issues is not the best way to start an installation with a new customer! Example questions: - File connection path for Bounce Processor Machine user permissions required Login details Etc. 13 Adding Epops to the Network Of course EPOPS delivered from the factory are essentially ‘ready for use’. They need to be added to a system before they can be assigned to products and display content. 13.1 Adding epops – step by step
Strictly Private & Confidential Page 25 of 37 © 2012 ZBD Displays Ltd 685-0003-08 The epops MUST be within 10m of the Bounce Communicator antenna to be configured 1. Adding epops to a network uses Channel 5 (in European territories) and Channel 60 in the USA. It is not possible to build two systems of epops for different stores using two machines in close proximity as there will be contention (conflict) for the same RF configuration channel. 2. Each box of EPOPS contains a number of 2D barcodes listing all the serial numbers of the EPOPS it contains. Record the label serial numbers using a 2D scanner into Notepad [or equivalent text editor] 3. Repeat for each box that you want to add in that session 4. Save the file and ensure all serial numbers are on separate lines and there are no gaps between lines or separator characters in the file. 5. Import this as a CSV file using Bounce Manager a. The process uses a list of epops in CSV format and configures each label, it then generates a list of successful and failed epops, any failures are automatically removed from the system making the installation clean. b. Failed epops should be re-run again – the Batch Configuration process results in a report which gives the option to rerun the configuration process again for any that have failed to configure. This should definitely be done. 6. Epops are then added by Bounce to the network automatically 7. Adding epops takes ~10 hours for circa 1,000 displays 8. The status progress can be viewed through the command line window or through the Batch Configuration Report in Bounce Manager. Once the process completes the total number of epops will be shown on the Bounce Manager Dashboard. 13.2 Offsite configuration If it is not practical to configure epops into a new installation (this could be due to construction delays, incomplete data cabling etc) then the configuration can be undertaken off-site. 1. Build a Bounce PC using the licence key for the installation 2. Configure the epops using Bounce Manager 3. Back up the database using Bounce Manager 4. Take the epops and the back up to the store and restore the database 5. After 15 minutes all of the epops should have resynchronised 6. Epops can be allocated to product in the normal way. 7. Delete the database from the off-site system and uninstall the software IMPORTANT NOTE: For sites that already have epops installed this process must NOT be used as it would generate duplicate RF addresses in the epops and could overwrite previous data changes in the live environment. If such a requirement is necessary contact support@zbdsolutions.com. 13.3 Synchronisation and Label Management In order for the system to function smoothly all epops should be kept in the store within range of the Bounce Communicator antenna. This is a ‘must do’
Strictly Private & Confidential Page 26 of 37 © 2012 ZBD Displays Ltd 685-0003-08 as staff need to be aware of some of the factors associated with how the RF system works. Part of the staff training must makes it clear that EPOPS that are out of range of the communicator will fail to update and will appear on a list of update failures. 13.3.1 Synchronisation The Bounce Communicator sends out ‘synch pulses’ in the background of normal operation so that all the EPOPS within range stay listening on a specific channel and react in a timely fashion to update commands. If the EPOPS are taken out of range of the communicator then they change state internally and begin listening on an alternative channel for RF commands. This is in order to conserve battery life when the epops may be out of RF range for an extended period When these epops are then brought back into RF range it can take a maximum of 20 minutes for them to regain synchronisation with the RF system and be available for the store staff to assign to products. Of course if the staff are not aware of this fact then their initial assessment when they try to allocate a ‘new’ label to a particular product may well be that ‘it doesn’t work’ and they will incorrectly report an error, not trust the system (or both) 13.3.2 Network Management Adding epops to the network (once the network is live) has to happen based on the rules outlined above i.e. within 2-10m of the Configure&Update communicator. Deleting epops from the network can be done from any distance from the communicator providing they are in range of course. 13.3.3 Moving epops between stores/sites Our recommendation is that when epops need to be taken from one store and sent to another then the following steps are taken:  Use a Hand Held Terminal (HHT) to delete epops from the network individually as you move around the store or scan the serial numbers of the epops that are going to be moved to create a .CSV file  If the HHT doesn’t have the ‘Delete EPOPS’ menu option then this would have to be done at the back office PC  Delete the EPOPS from the system using Bounce Manager  There is now a DeleteEPOPS command line tool that can delete a large number of EPOPS listed in a csv file. This is run from a command line and the tool can be found in the c:\Program Files\ZBDDisplays\Bounce\Tools\DeleteEpops folder  Epops that have been deleted from the network in the store will be blank  Take the CSV list of deleted EPOPS and import this into Bounce Manager in the second store while the epops are within 2-10m of the new Bounce Communicator Antenna  The main point with label management, movement and setting up the system is that a pre-planned process should always be followed.  Taking ‘ad-hoc’ action to fix a problem, however urgent or justifiable in the short term, can very easily create long term issues requiring numerous store visits to correct. 14 Product Data Loading As well as adding physical epops to the system the products have to be created for them to be linked to. The settings defined in Policy Architect come into effect when Bounce Processor runs and the Bounce Database is populated with product information. This product data is then used by Processor to create bitmap images for each product using the rules that were defined in Template Architect
Strictly Private & Confidential Page 27 of 37 © 2012 ZBD Displays Ltd 685-0003-08 Bounce Processor (acquire phase)Policy ArchitectConfigurationData Values- Data sources- Product Data Fields- Template Fields- TransformationsBounce Processor (render phase)Policy ArchitectConfiguration - Template FieldsTemplateCollectionBounceDatabaseBounceCommunicatePolicy ArchitectConfiguration - Schedule infoPriceModelStockRetailer DatabasesTableTableTablebounce ArchitectDatabase 14.1 ‘Enterprise’ Interface product data loading In this case Bounce Processor is monitoring a folder on the local machine in each store for incoming XML product information. So the first stage is to begin an ‘initial load’ of product data which has to be started by the retailer’s systems. Sending all the product information for the store means Bounce Processor has a starting image/dataset for a product. Any new information for a product is compared to what’s already in the database and a new bitmap created and sent out if needed. 14.2 Other connection types Bounce Processor will read the data from a database or .csv file (for example) and then store a local copy of the information it needs. Depending on the rules defined in the policy file, Bounce Processor with then re-read the database and send out updates with new images if needed. 15 Linking epops to Products Essentially there are a couple of scenarios to consider.  A small store with up to a hundred epops  A medium store with 100 to 1,000’s  A large store with 1,000’s to 10,000’s Unless it’s a very small installation the only practical way of linking EPOPS to products is by using a mobile hand-held terminal (HHT) that has a barcode scanner. Store staff can go along a shelf scanning a product barcode and then an EPOPS barcode to associate or ‘link’ the two in the database. This will trigger Bounce Communicate to send a product image to the EPOPS. If the product information changes then another image will be sent to that label automatically. There are a few ways to set this up in the software and this is a very important process that needs to be fully discussed with the customer before a solution is implemented.
Strictly Private & Confidential Page 28 of 37 © 2012 ZBD Displays Ltd 685-0003-08 It should be noted that medium and large stores will have their own locked down HHT application. ZBD and partners can only advise on techniques to implement. It is entirely the customers responsibility to integrate, test and approve any HHT application. 15.1 XML or ‘Enterprise’ interface method This is the most flexible and easy to implement way of linking EPOPS to products because it can be programmed by the retailer so they are using their own HHT. It also means that the links can still be made if the retailer doesn’t have a wireless network in their store. (batch) <link> <art>121525800000</art> <label>012345678900000040</label> <linktype>LINK</linktype> </link> - <link> <art>121525800000</art> <label>012345678900000060</label> <linktype>UNLINK</linktype> </link> 15.2 ZBD Bounce Manager – Product Assignment There is nothing built into Bounce Manager in the current release. Should you require the ability to do this in Bounce Manager, please contact support@zbdsolutions.com
Strictly Private & Confidential Page 29 of 37 © 2012 ZBD Displays Ltd 685-0003-08 16 Training and Procedures before handover 16.1 Training Staff training is a very important part of the success of any project. Since the staff are such a key part of any retail organisation their opinion and user experience carries great weight with any decision making process later in the sale. Staff training must incorporate the basic functionality such as: o Knowing how to access the Bounce Manager application o How to use the HHT application device o How to manually assign/un-assign epops to products o How to manually add/delete epops to the system o The correct handling and care of the epops [cleaning etc] o Use of the built-in scanner to read bar-codes effectively. o Ongoing training to ensure all operators can use scanners correctly. o How to attach/remove epops from fixtures and correct use of fittings (i.e. to optimize viewing angles etc.) o The correct thermal stabilization (thermal equilibrium) period if epops are moved from ambient temperature to “chiller” environments or vice versa. It is recommended that display image updates are not carried out during the 45min thermal stabilization period. If updates are carried out the image will be blackened or smudged and the correct time must elapse before a new image update is downloaded which will correct the smudged image. The staff should have access to User Guides that they can use to administer the labeling system; these documents should be the responsibility of the customer or agent to provide. We recommend getting hold of any ‘User Guides’ created by the customer to check that what they’ve created is correct and clear. 16.2 Procedures and handover Retailers usually have a pre-defined set of procedures and will know what their roles and responsibilities are in most situations. These scenarios need to be discussed and agreed with the project team before the system is handed over to them. Does the project team know how the store gets more EPOPS? What’s the procedure for reporting faults or issues? Unless these are dealt with before the store takes over responsibility for the system then the whole installation may fail. The handover process should confirm that the store management has accepted the system, and these processes have been agreed. o Staff training & supporting procedures documentation (eg: Quick Reference Guide) o Support contact information (who to call, how to escalate). o Typically in the form of an A4/A5 o Support Notice with information and contact numbers o Where to get spares displays, shelf-edging or other consumables?
Strictly Private & Confidential Page 30 of 37 © 2012 ZBD Displays Ltd 685-0003-08 o Returns Management Process has been agreed and the store management knows what it is. So, the staff will know what to do if there’s a problem, where to get more epops from and they’ll have had training. 17 System Management The system is managed through the Bounce Manager application and provides status updates, reports and alerts. The Bounce Manager application guide is documented in 530-0058-xx (Bounce Manager User Guide). This document is very important and must be read before the system is made operational 18 Support Overview Issues that need ZBD assistance should be sent via our support email address (Salesforce portal) with all the necessary information to be able to reproduce the problem. support@zbdsolutions.com In most cases ZBD are likely to be responsible for third level support only. So partners will provide the first and second level support for most system installations whether they are trials, proof of concept or full roll-out. ZBD will deal with third level support issues once the partner has been able to reproduce the issue themselves in-house and is able to give ZBD the means to reproduce the issue in order to fix it. The different parts of the Bounce software suite all have logs available on the live system to help diagnose issues and solve problems. This support section focuses on the XML based ‘Enterprise Interface’ [550-0009-xx] since this is our preferred method of driving the system. This offers the greatest flexibility for interfacing to the system and controlling it without significant integration/coding work needing to be carried out. This support chapter has been split into three sections: - 1. Store level diagnostics Information and questions for store personnel to help them either solve the problem themselves or help in the diagnosis 2. Partner / Support level diagnostics Locations for support logs and some information on mid-level issues that can occur as well as how to fix them 3. Advanced Selected challenges and more detailed information 18.1 Store level diagnostics The main challenge with problems reported by store staff is lack of information that’s useful to actually solve the problem. These are usually vague statements like: - ‘Nothing seems to be working’
Strictly Private & Confidential Page 31 of 37 © 2012 ZBD Displays Ltd 685-0003-08 ‘A label didn’t update’ ‘A price change didn’t happen’ Instead of trying to use this vague information as the basis for diagnosing the fault and fixing the problem it’s actually more time efficient to go through a set number of steps. 18.1.1 Is the RF network working? There are a couple of ways for staff to check whether the RF network is actually functioning properly 18.1.1.1 Is the green or orange light flashing on the communicator? This may not be visible to the staff, depending on where it is mounted in the store 18.1.1.2 Can you assign an EPOPS to a different product? Pick an EPOPS from the shop floor and try to assign it to something different (remember to assign it back afterwards!) Try a couple if the first attempt doesn’t work – remember, depending on the way the system is set up, that there may be a wait for this action to complete. 18.1.1.3 What is the general system status? There is an alert log in Bounce Manager and visible alerting in the Dashboard to warn the store staff whether there are significant problems anywhere with the system 18.1.2 What’s the status of the label? It’s important to find out from the staff what the label actually says: - ‘Successfully configured’* The label is on the network but has never been linked to a product ‘Unassigned’* The label is on the network and was linked to a product but is not linked to a product anymore ‘No image available’* The label is assigned/linked to a product but the problem could be that the product information isn’t available from the retailer’s host system [see section 13.2.1.2 later] ‘Product image bitmap’ The label has a product image with price/barcode etc. means that it’s currently linked to the product shown *It is possible in some environments that these default images have been replaced with specific customer images.
Strictly Private & Confidential Page 32 of 37 © 2012 ZBD Displays Ltd 685-0003-08 18.1.2.1 Interrogate Bounce Manager about the label In order for store staff to interrogate the system about a specific EPOPS look at the Bounce Manager page and type/scan its serial number into EPOPS History 18.1.2.2 Force the label to update Using the HHT it may be possible to force the label to update or to use the retailer’s host system to send the product information to the label again. REMEMBER: The store back office system may be out of range of the communicator if it’s sitting out in the middle of the sales area. Holding a label and trying to send it updates when out of range of the communicator is obviously going to cause even more confusion! 18.1.2.3 Is the label update or assignment in the Update Queue? Apart from sitting and looking at a label and maybe missing changes on the screen it’s possible to check the bounce queue in Bounce Manager 18.2 Partner / Support Level Diagnostics We recommend that partners and support organisations should have remote access to the machines running the Bounce software in store. The main reason for this is that EPOPS are still quite ‘new’ technology and while we are confident the solution is robust the customer will be nervous about relying on something they may not understand. So it is very important for support organisations to be able to react quickly and answer questions that the customer might have. The only way to really achieve this is by having remote access to the machine in the store. 18.2.1 Enterprise Interface error logging The main advantage of using XML files and folders is that files (product updates, link requests and system commands) which aren’t processed are moved into their respective error folders. So it’s easy to see whether files have been processed or not. More detail on setting up the system this way is available in the Enterprise Interface [550-0009-] There is also a general ‘logging output file’ which can be activated in Policy Architect. Policy Architect > Edit > Logging Settings [The schema file for this is available from the ZBD technical team] All this information can be accessed by the retailer’s host system and used to send status information back to the organisation – rather than having to rely on store staff managing the system and trying to diagnose issues themselves.
Strictly Private & Confidential Page 33 of 37 © 2012 ZBD Displays Ltd 685-0003-08 18.2.1.1 Incoming XML data doesn’t match the Schema If files are sent from the host system that don’t match the schema for the products, EPOPS or system commands then they won’t be processed and re-named as errors 18.2.1.2 XML files didn’t actually arrive to be processed There may be a classification of products or a switch higher up within the retailer’s host system that means products aren’t categorised or available as ‘electronic epops’ We’ve seen this where the request is made to the host system for the information for a particular product but he host has ignored this request because that particular product shouldn’t be merchandised (sold) using an electronic label. 18.2.2 Error logs There are quite a few logs available to diagnose system issues although it takes some experience to draw conclusions from them. 18.2.3 System Management Tools In the latest release (3.3) there are a number of command line tools which are designed to carry out batch processes, solve problems and diagnose possible faults across the network of epops in the store. 18.2.3.3 Bounce Processor Database Cleaning Tool The Bounce Processor Database Cleaning Tool is a command line application that is designed to remove unused data from the Bounce Processor SQL Server database instance and reclaim storage space. The tool requires no user interaction and can therefore be used from a scheduled task within Windows. [530-0034-xx] 18.2.3.4 SQL Database Cleanup Tool The SQL Database Cleanup Tool is a command line application that is designed to remove unused data from the Bounce SQL Server database instance and reclaim storage space. The tool requires no user interaction and can therefore be used from a scheduled task within Windows. [530-0032-xx] Both these cleanup tools should be scheduled to run in installations to ensure that SQL Express 2008 does not reach it’s 10GB data limit.
Strictly Private & Confidential Page 34 of 37 © 2012 ZBD Displays Ltd 685-0003-08 18.2.3.5 Get Log Tool This tool copies and zips all the log files for the system and places the zip file in the same directory that the batch file was run from. The default location for this is: - C:\Program Files\ZBD Displays\Bounce\Tools\GetLogFiles This saves users hunting around locations for all the logs and brings them together into one place. It does not send the file anywhere however! When logging a support request it is good practice to include the zipped log files in the request. 18.2.3.6 SQLBounceXMLBackup and SQLBounceXMLRestore These tools create an XML based backup of the Bounce Comms database but only retain the information needed to recover a network of EPOPS with their product associations. Since the amount of information retained is less these files are not as big as standard SQL backups so they can be emailed and sent without the same network issues that a 300Mb file might have. 18.2.3.7 BackupDB Tool A standalone tool for backing up the bounce database 18.2.3.8 EPOPS Command Line Application (CLA) The CLA tool is a powerful command line application that should only be used when directed to by ZBD Support. Making improper changes to the system using this tool can have a detrimental effect on the system and in some cases loose communication to the EPOPS altogether. Please refer to the detailed notes in the documentation for this tool [530-0037-xx] 18.2.4 Other ZBD Software Tools These utilities are available to make batch tasks simpler and save time 18.2.4.1 Auto EPOPS Assign Allows you to assign a .csv file or EPOPS serial numbers to a .csv file of product ID’s automatically. The next EPOPS serial number in the list will be associated (linked) to the next product in the list. It’s also possible to use Auto EPOPS Assign to automatically link an EPOPS serial number list to products with the same ID as the EPOPS serial numbers. [530-0036-xx] 18.2.4.2 Delete EPOPS Allows mass deletion of a .csv list of EPOPS serial numbers from a system without having to find individual EPOPS in the Bounce GUI list [530-0035-xx]
Strictly Private & Confidential Page 35 of 37 © 2012 ZBD Displays Ltd 685-0003-08 19 Summary The main challenges to set up a working system are: - o Understanding the retailer’s wishes for the system and the procedures that have to be followed in the store. o Agreeing a written technical specification that meets these requirements and get signoff by both parties. o Planning the installation to take into account lead-times and fixtures/fittings. o Following a set of logical, sequential steps while installing the EPOPS solution. o Ensuring the staff have received proper training from the retailer. We hope this document will greatly assist in meeting these challenges and welcome any feedback.
Strictly Private & Confidential Page 36 of 37 © 2012 ZBD Displays Ltd 685-0003-08 20 Appendix A – Bounce Manager installation Bounce Manager can be installed in either of 2 modes: either in Standalone mode or in IIS mode. In Standalone mode, access to Bounce Manager is restricted to the PC on which it is installed. In IIS mode, Bounce Manager can be accessed from remote PCs. The installation and correct configuration of Microsoft Internet Information Services (IIS) is a pre-requisite in this case. Installation files: the Bounce Manager installation package contains 2 folders ‘Standalone’ and ‘IIS’. The ‘Standalone’ folder contains the Bounce Manager installation files (setup.exe and BounceManagerSetup.msi) which install Bounce Manager as a web service running on TCP/IP port 8000. If Bounce Manager is installed as ‘Standalone’ it will only be available on the PC on which it is installed via http://localhost:8000/. [N.B – please run the file setup.exe to install] If access to Bounce Manager is required from a remote PC, then the ‘IIS’ alternative needs to be installed. The ‘IIS’ folder contains the installation files (setup.exe and BounceManagerIISSetup.msi) which install Bounce Manager as a module or web application under Microsoft Internet Information Services (IIS). [N.B – please run the file setup.exe to install] Configuration steps: The ‘IIS’ option requires a number of configuration steps, as listed below: (1)Enable ‘IIS 6 Management Compatibility’ The location of this Windows module depends on your operating system – please refer to Windows documentation for more details. Under Windows 2008 Server R2 64-bit the ‘IIS 6 Management Compatibility’ module can be found under Web Server (IIS), ‘Add Role Services’ and select ‘IIS 6 Management Compatibility’. Under Windows 7 32-bit, the ‘IIS 6 Management Compatibility’ module can be found in “Control Panel > Programs & Features > Turn Windows features on or off”. Figure 1 - enable IIS 6 management compatibility (2) Bounce Manager runs under the DefaultAppPool under IIS.
Strictly Private & Confidential Page 37 of 37 © 2012 ZBD Displays Ltd 685-0003-08 For Bounce Manager to function correctly, please ensure that the following parameters are set correctly in the Advanced Settings of the DefaultAppPool. a. Under section (General) , and if Bounce Manager is running on a 64-bit system, please set Enable 32-bit Applications to True – see Figure 2 below. b. Under section Process Model, please set Load User Profile to True. Figure 2 - IIS DefaultAppPool parameters

Navigation menu