Displaydata 120-0112 Aura 29 Electronic Label User Manual Manual

Download:
Mirror Download [FCC.gov]
Document ID	2210849
Application ID	JzCxE2EWBNC1vQVTMZQMEw==
Document Description	Manual
Short Term Confidential	No
Permanent Confidential	No
Supercede	No
Document Type	User Manual
Display Format	Adobe Acrobat PDF - pdf
Filesize	47.1kB (588763 bits)
Date Submitted	2014-03-10 00:00:00
Date Available	2014-03-10 00:00:00
Creation Date	2014-03-10 14:19:36
Producing Software	Acrobat Distiller 11.0 (Windows)
Document Lastmod	2014-03-10 14:19:36
Document Title	Microsoft Word - 685-0003-08 System Installation Guide
Document Creator	PScript5.dll Version 5.2.2
Document Author:	rsweetman

System Installation Guide
for v3.3 Software Release
Document Number:
Date:
st
21
685-0003-08
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)
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!
Change History
Date
24Feb2011
Version
02
Author
Changes
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
© 2012 ZBD Displays Ltd
Page 2 of 37
685-0003-08
3
Table of Contents
Scope ___________________________________________________________________ 2
Change History ___________________________________________________________ 2
Table of Contents__________________________________________________________ 3
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
External Documents - Caution ______________________________________________ 13
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
Site Survey ______________________________________________________________ 17
7.1
Site Survey basics ___________________________________________________________ 17
7.2
RF Range testing and positioning the communicator ______________________________ 17
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.3
7.3.1
7.3.2
7.3.3
RF Range Test tool _______________________________________________________________ 17
RSSI scan ______________________________________________________________________ 17
Smaller format stores (approx. 5000 m2) ______________________________________________ 17
Larger format stores ______________________________________________________________ 17
Environmental considerations ______________________________________________________ 17
Note the position of the IT infrastructure ______________________________________________ 18
Fixtures and Fittings ________________________________________________________ 19
HL Display and Sitour. ____________________________________________________________ 19
EPOPS ‘Angling’ ________________________________________________________________ 19
Ongoing Staff maintenance ________________________________________________________ 20
Training ________________________________________________________________ 20
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 3 of 37
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
12.3.2
12.3.3
13
Synchronisation _________________________________________________________________ 26
Network Management ____________________________________________________________ 26
Moving epops between stores/sites __________________________________________________ 26
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
17.1.2
17.2
Is the RF network working? ________________________________________________________ 31
What’s the status of the label? ______________________________________________________ 31
Partner / Support Level Diagnostics __________________________________________ 32
17.2.1
17.2.2
17.2.3
17.2.4
Enterprise Interface error logging____________________________________________________ 32
Error logs ______________________________________________________________________ 33
System Management Tools ________________________________________________________ 33
Other ZBD Software Tools ________________________________________________________ 34
18
Summary______________________________________________________________ 35
19
Appendix A – Bounce Manager installation__________________________________ 36
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 4 of 37
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
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
© 2012 ZBD Displays Ltd
Page 5 of 37
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
5.2
Overview Diagram
5.3
Bounce Architect
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.
Component
Description
Policy Architect
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.
(Define data
sources,
transformations &
template fields)
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
© 2012 ZBD Displays Ltd
Page 6 of 37
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
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.
(Acquire/Transform/Render)
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
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.
(Transmit, Log)
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 7 of 37
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
The Configuration component consists of a web application
that enables Users to remotely configure and control the
Bounce Processor product.
(Configuration,
Assign, Report)
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
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 8 of 37
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
Product Data Fields
Link
Transformation
SKU
SKU
Price Db
Price
Price
Description
Template Fields
[PromoPrice] = [Price] * 0.8
PromoPrice
Description
Brand
Model
StockLevel
Template
SKU
Model Db
Brand
Policy Rules
Model
[StockLevel] =
If [Stock] > 100 Then “In Stock”
Else If [Stock] = 0 Then “Out of Stock”
Else “Low Stock”
SKU
Stock Db
Stock
‘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
© 2012 ZBD Displays Ltd
Page 9 of 37
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
© 2012 ZBD Displays Ltd
Page 10 of 37
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
© 2012 ZBD Displays Ltd
Page 11 of 37
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
© 2012 ZBD Displays Ltd
Page 12 of 37
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.
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
© 2012 ZBD Displays Ltd
Page 13 of 37
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
© 2012 ZBD Displays Ltd
Page 14 of 37
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
© 2012 ZBD Displays Ltd
Page 15 of 37
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
© 2012 ZBD Displays Ltd
Page 16 of 37
685-0003-08
Check network access
7.6
(Switch port available, cabling type)
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.
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
© 2012 ZBD Displays Ltd
Page 17 of 37
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)
Medicines
350
Mens Health
250
Nail & Accesories
500
Nails
150
Oils
200
Prepared Meals
400
Toys & Gifts
Freezer
750
500
etc.
Medicines
Health Products
Nails
Oils
Prepared Meals
Toys
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.
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 18 of 37
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.
Above 2M: 15o Negative
1M – 2M: Neutral
Below 1M: 15o Positive
Bottom ledge: 45o
(should be protected
by Bumper Bar)
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 19 of 37
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.
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
© 2012 ZBD Displays Ltd
Page 20 of 37
685-0003-08
11 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.
bou nce
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 21 of 37
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
© 2012 ZBD Displays Ltd
Page 22 of 37
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
© 2012 ZBD Displays Ltd
Page 23 of 37
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
© 2012 ZBD Displays Ltd
Page 24 of 37
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
© 2012 ZBD Displays Ltd
Page 25 of 37
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
© 2012 ZBD Displays Ltd
Page 26 of 37
685-0003-08
Policy Architect
Configuration
- Data sources
- Product Data Fields
- Template Fields
- Transformations
Table
Policy Architect
Configuration
- Template Fields
Policy Architect
Configuration
- Schedule info
Data
Values
Table
Bounce
Processor
(acquire phase)
Table
Price
Model
Stock
Retailer Databases
Bounce
Processor
(render phase)
Bounce
Communicate
bounce Architect
Database
Template
Collection
Bounce
Database
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
© 2012 ZBD Displays Ltd
Page 27 of 37
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)

121525800000
012345678900000040
LINK

- 
121525800000
012345678900000060
UNLINK

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
© 2012 ZBD Displays Ltd
Page 28 of 37
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:
Knowing how to access the Bounce Manager application
How to use the HHT application device
How to manually assign/un-assign epops to products
How to manually add/delete epops to the system
The correct handling and care of the epops [cleaning etc]
Use of the built-in scanner to read bar-codes effectively.
Ongoing training to ensure all operators can use scanners correctly.
How to attach/remove epops from fixtures and correct use of fittings
(i.e. to optimize viewing angles etc.)
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.
Staff training & supporting procedures documentation (eg: Quick
Reference Guide)
Support contact information (who to call, how to escalate).
Typically in the form of an A4/A5
Support Notice with information and contact numbers
Where to get spares displays, shelf-edging or other consumables?
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 29 of 37
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’ [5500009-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
© 2012 ZBD Displays Ltd
Page 30 of 37
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
© 2012 ZBD Displays Ltd
Page 31 of 37
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 [5500009-]
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
© 2012 ZBD Displays Ltd
Page 32 of 37
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
© 2012 ZBD Displays Ltd
Page 33 of 37
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
© 2012 ZBD Displays Ltd
Page 34 of 37
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.
Agreeing a written technical specification that meets these requirements
and get signoff by both parties.
Planning the installation to take into account lead-times and
fixtures/fittings.
Following a set of logical, sequential steps while installing the EPOPS
solution.
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
© 2012 ZBD Displays Ltd
Page 35 of 37
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
© 2012 ZBD Displays Ltd
Page 36 of 37
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
Strictly Private & Confidential
© 2012 ZBD Displays Ltd
Page 37 of 37
685-0003-08

---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : Yes
Author                          : rsweetman
Create Date                     : 2014:03:10 14:19:36Z
Modify Date                     : 2014:03:10 14:19:36Z
XMP Toolkit                     : Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03
Creator Tool                    : PScript5.dll Version 5.2.2
Producer                        : Acrobat Distiller 11.0 (Windows)
Format                          : application/pdf
Title                           : Microsoft Word - 685-0003-08 System Installation Guide
Creator                         : rsweetman
Document ID                     : uuid:bc4cae48-8f65-4c2e-9e71-2e2d70a72576
Instance ID                     : uuid:f33a7dca-efc9-458b-bf52-5e97d90062d4
Page Count                      : 37

EXIF Metadata provided by EXIF.tools