DRAFT UGANDA STANDARD  
  DUS 25 80: 
2022  
First  Edition  
yyyy -mm-dd 
 
 
 Reference number  
DUS 2580: 2022  
© UNBS yyyy   
  
Gaming equipment  — On-Line Monitoring and Control Systems 
(MCS) and Validation Systems  — requirements  
 DUS 2580: 2022  
ii © UNBS yyyy  – All rights reserved  
 Compliance with this standard does not, of itself confer immunity from legal obligations  
A Uganda Standard does not purport to include all necessary p rovisions of a contract. Users are 
responsible for its correct application  
© UNBS yyyy  
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilised in any 
form or by any means, electronic or mechanical, includ ing photocopying and microfilm, without prior written 
permission from UNBS.  
Requests for permission to reproduce this document should be addressed to  
The Executive Director  
Uganda National Bureau of Standards  
P.O. Box 6329  
Kampala  
Uganda  
Tel: +256 414 333 250/1/2/3  
Fax: +256 414 286 123  
E-mail: info@unbs.go.ug  
Web: www.unbs.go.ug  DUS 2580: 2022  
© UNBS yyyy  – All rights reserve d iii 
 Contents  Page 
Foreword  ................................ ................................ ................................ ................................ ............................  iv 
Introduction  ................................ ................................ ................................ ................................ .......................  vii 
1 Scope  ................................ ................................ ................................ ................................ ......................  1 
2 Conformance  ................................ ................................ ............................. Error! Bookmark not defined.  
3 Normative references  ................................ ................................ ................................ ............................  1 
4 Terms and definitions  ................................ ................................ ................................ ...........................  2 
5 Symbols (and abbreviated terms)  ................................ ................................ ................................ ........  2 
6 Clause  ................................ ................................ ................................ ......... Error! Bookmark not defined.  
6.1 Subclause (level  1) ................................ ................................ .................... Error! Bookmark not defined.  
6.1.1 Subclause (level  2) ................................ ................................ .................... Error! Bookmark not defined.  
6.1.2 Subclause (level  2) ................................ ................................ .................... Error! Bookmark not defined.  
6.2 Subclause (level  1) ................................ ................................ .................... Error! Bookmark not defined.  
7 Clause  ................................ ................................ ................................ ......... Error! Bookmark not defined.  
8 Special  ................................ ................................ ................................ ........ Error! Bookmark not defined.  
Annex  A (normative)   Annex title  ................................ ................................ ................................ .....................  19 
A.1 General  ................................ ................................ ................................ ................................ .................  19 
A.2 Clause  ................................ ................................ ................................ ................................ ...................  19 
A.2.1 Subclause (level  1) ................................ ................................ ................................ ..............................  19 
A.2.2 Subclause (level  1) ................................ ................................ ................................ ..............................  19 
A.3 Clause  ................................ ................................ ................................ ................................ ...................  19 
Annex  B (informative)   Which styles correspond to which element  — Quick reference guide  .................  21 
Bibliography  ................................ ................................ ................................ ................................ ......................  24 
 DUS 2580: 2022  
iv © UNBS yyyy  – All rights reserved  
 Foreword  
Uganda National Bureau of Stand ards (UNBS) is a parastatal under the Ministry of Trade, Industry and 
Cooperatives established under Cap 327, of the Laws of Uganda, as amended.  UNBS is mandated to co -
ordinate the elaboration of standards and is  
(a) a member of International Organisation fo r Standardisation (ISO) and  
(b) a contact point for the WHO/FAO Codex Alimentarius Commission on Food Standards, and  
(c) the National Enquiry Point on TBT Agreement of the World Trade Organisation (WTO).  
The work of preparing Uganda Standards is carried out thro ugh Technical Committees. A Technical 
Committee is established to deliberate on standards in a given field or area and consists of key stakeholders 
including government, academia, consumer groups, private sector and other interested parties.  
Draft Uganda Standards adopted by the Technical Committee are widely circulated to stakeholders and the 
general public for comments. The committee reviews the comments before recommending the draft standards 
for approval and declaration as Uganda Standards by the Natio nal Standards Council.  
The committee responsible for this document is Technical Committee UNBS/TC ###, [name of committee] , 
Subcommittee SC ##, [name of subcommittee] . 
This second/third/… edition cancels and replaces the first/second/… edition (US nnn-n:yyyy), which has been 
technically revised.  
US nnn consists of the following parts, under the general title Introductory element — Main element :  
  Part n: Part title  
  Part [n+1]: Part title  
  Part [n+2]: Part title  
The purpose of this document is to esta blish the requirements for the design and operation of gaming 
equipment  within the jurisdiction of Uganda  and to guide testing and certification bodies on the areas for 
technical compliance for the On-Line Monitoring and Control Systems (MCS) and Validatio n Systems .   
The intent of this document is to ensure that gaming on electronic gaming equipment  occur in a manner that 
is:-  
a. Honest;  
b. Secure;  
c. Reliable; and  DUS 2580: 2022  
© UNBS yyyy  – All rights reserve d v 
 d. Auditable.  
 It is not the intent of this document to: -  
a. Mandate a single solution or method t o realise an objective;  
b. Limit technology application to gaming equipment;  
c. Limit creativity and variety of choice;  
d. Preclude research and development into new technologies equipment or innovative ideas.  
As far as possible, this document specifie s what the minimum technical requirements for electronic gaming 
equipment  are instead of how the requirements should be met; nor try to mandate a particular solution or 
method as the means to realise the requirements.  
The responsible authority  supervises and regulates the activities of casinos in Singapore. Casino operators 
are required to be licensed by law and shall ensure that their gaming equipment  deployed on the casino floor 
comply with these technical standards.  
These technical standards are supple mentary to and are not intended to derogate from any provisions in the 
….    and its subsidiary legislations. In the event of any consistency, the provisions in the …………… Act 
(Cap. ….) and its subsidiary legislations shall apply.   
These standards are subj ect to on -going review, and where necessary or deemed appropriate, the Authority 
reserves the right to unilaterally amend or re -issue this document without notice. The foreword  shall appear in 
each standard. It shall not contain requirements, figures or ta bles.  
In addition to the appropriate boilerplate text (see above) give the designation and name of the committee that 
prepared the standard, together with as many of the following as are appropriate:  
— an indication of any other international organization that has contributed to the preparation of the 
standard;  
— a statement that the standard cancels and replaces other documents in whole or in part;  
— a statement of significant technical changes from the previous edition of the standard;  
— the relationship of the standard to other standards or other documents;  DUS 2580: 2022  
vi © UNBS yyyy  – All rights reserved  
 — a statement specifying which annexes are normative and which are informative.  DUS 2580: 2022  
© UNBS yyyy  – All rights reserve d vii 
 Introduction  
1.1 An On -line Monitoring and Control System (MCS) is a game management system that continuously 
monitors e ach Electronic Gaming Device via a defined communication protocol by either a dedicated line, dial -
up system, or other secure transmission method. A MCS is primarily tasked to provide logging, searching, and 
reporting of gaming Significant Events, collecti on of individual device financial and meter data, reconciliation of 
meter data against hard and s oft counts, and System Security.  
Phases of Certification.    
a) The approval of an On -line Monitoring and Control System shall be certified in two phases:  
b) Initial  laboratory testing, where the laboratory will test the integrity of the system in conjunction with 
Gaming Devices, in the laboratory setting with the equipment assembled; and  
c) On-site certification where the communications and set up are tested on the cas ino floor prior to 
implementation.  
1.1 Graphical Overview  
1.2.1  General Statement .   
The purpose of this section is to lend a visual depiction of a generic On -line Monitoring and controls computer 
system and is not intended to mandate any particular compo nent or system topology providing functionality is 
maintained.  The terms used throughout this document will be represented in a block diagram format to clarify 
individual components.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
In the illustration above, thi s standard applies to all components referenced other than the Gaming Device.  
The requirements for the Gaming Device are defined in the standards for Gaming Devices. This document will 
only concern communications from the Gaming Device to the MCS, and not  in the reverse order, with the 
exception of the Ticket/Voucher Validation System Requirements that are incorporated within Chapter 4.  
 Multiple  
Gaming 
Devices  Gaming Devic e 
Interface Element  
 
Data Collectors  
 
Front End Processor  
(FEP)  
 Multiple  
DC’s  
Monitoring And 
Control Systems  
(MCS)  
Servers w/ Databases & Workstations  
 DUS 2580: 2022  
viii © UNBS yyyy  – All rights reserved  
 1.3  Purpose of Standard  
1.3.1  General Statement.   
The purpose of this standard is as follows:  
a) To eliminate subjective criteria in analyzing and certifying gaming Monitoring and Control System 
operation.  
b) To only test those criteria which impact the credibility and integrity of gaming from both the Revenue 
Collection and game play point of view.  
c) To create a standard that wi ll insure that On -Line Monitoring and Control Systems (MCS) And Validation 
Systems are fair, secure, and able to be audited and operated correctly.  
d) To distinguish between local public policy and laboratory criteria.   
e) To recognize that non -gaming testing ( such as Electrical Testing) should not be incorporated into this 
standard but left to appropriate test laboratories that specialize in that type of testing. Except where 
specifically identified in the standard, testing is not directed at health or safety m atters. These matters are 
the responsibility of the manufacturer, purchaser, and operator of the equipment.  
f) To construct a standard that can be easily changed or modified to allow for new technology.  
g) To construct a standard that does not specify any parti cular technology, method, or algorithm.  The intent 
is to allow a wide range of methods to be used to conform to the standards, while at the same time, to 
encourage new methods to be developed.  
1.3.2  No Limitation of Technology.   
One should be cautioned t hat this document should not be read in such a way that limits the use of future 
technology.  The document should not be interpreted that if the technology is not mentioned, then it is not 
allowed.   
 DRAFT UGANDA STANDARD  DUS 2580: 2022  
 
© UNBS yyyy – All rights reserved  1 
 Gaming equipment — monitoring and control system  — 
requirements   
1 Scope  
The scope of  this DUS standard provides requirements for  On-Line Monitoring and Control Systems (MCS) 
and Validation System requirements necessary to achieve certification when interfaced to Gaming Devices, 
for the purpose of communicating mandatory  security events and electronic meters. This infers that all 
relevant monetary transactions at the Gaming Device level are handled through:  
a) Credit Issuance:  
i. Coins or tokens accepted via approved coin acceptors;  
ii. Currency notes (Bills) accepted via approved  bill validators; and  
iii. Approved Ticket/Voucher (Items) accepted via approved Bill/ Ticket/Voucher validators; or  
iv. Player Account Cards (cashless)  
b) Credit Redemption:  
i. Coins or tokens paid by approved hoppers;  
ii. Handpays;  
iii. Ticket/Voucher (Items) paid by approved ticket/voucher printers; or  
iv. Player Account Cards (cashless).  
1.1 Exceptions to Standard  
This standard does not govern MCS requirements for any other form of monetary transaction.  This standard 
also does not govern advanced bi -directional communication pro tocols (i.e. EFT, AFT, Bonusing, Promotional, 
System Based Progressives, features that utilize an RNG, etc.) that support credit transfer between Gaming 
Device and MCS.  This standard only supports one -way communication of events originated at the Gaming 
Device level to the MCS with the exception of the Ticket/Voucher Validation System Requirements that are 
incorporated within clause 4.  This standard does not exclude Gaming Devices that operate with Player 
Account Cashless transactions for the purpose of c ommunicating mandatory security events and electronic 
meters.  This infers that all relevant monetary transactions at the EGD level are handled via electronic transfer 
through a secure communication protocol.  These device types shall meet the applicable r equirements set 
forth herein, specifically governing metering information and significant events in addition to other  standards 
that may apply. . 
2 Normative references  
There are no normative references in this document.  DUS 2580: 2022  
2 © UNBS yyyy – All rights reserved  
 3 Terms and definitions  
3.1  
 
Authority    
The body that is  responsible for regulating gaming devices and equipment.  
3.2  
Authentication    
Process of determining if the source of the program is legitimate and valid.  
3.3  
Critical Memory   
Memory locations storing data that is considered v ital to the continued proper operation of the device. The 
contents of critical memory may include, but not be limited to device configuration data and game 
configuration data.   
3.4  
Electrostatic Interference (ESI)  
Physical property of being able to crea te electronic interference to a device by either discharging static 
electricity onto the surface of the unit (such as from a user) or via a mains power or communication cable 
(from lightning for example).  
3.5  
Random Number Generator (RNG)   
Hardware, sof tware or combination device for generating number values that exhibits characteristics of 
randomness.  
3.6  
Verification   
Process of checking that the content of the program is not corrupted.  
4 System Component  Requirements  
4.1 Interface Element Requireme nts 
4.1.1   General Statement.   Each Gaming Device installed in the casino shall have a device or 
facility (interface element) installed inside a secure area of the Gaming Device, that provides for 
communication between the Gaming Device and an external Da ta Collector.  
4.1.2   Metering Requirements.  If not directly communicating Gaming Device meters, the interface 
element shall maintain separate electronic meters, of sufficient length, to preclude the loss of 
information from meter rollovers, or a means to identify multiple rollovers, as provided for in the 
connected Gaming Device.  These electronic meters should be capable of being reviewed on DUS 2580: 2022  
© UNBS yyyy – All rights reserved  3 
 demand, at the interface element level via an authorized access method, see also clause  4.3 
‘Meters.’  
4.1.3 Battery  Backup Requirements.   
The interface element shall retain the required information after a power loss for a period 
determined by the regulatory agency.  If this data is stored in volatile RAM, a battery backup shall 
be installed within the interface eleme nt, see also clause  4.3 ‘Meters .’ 
4.1.4 Information Buffering.   
If unable to communicate the required information to the MCS, the interface element shall provide a 
means to preserve all mandatory meter and significant event information until such time as it can be 
communicated to the MCS, see also clause  4.2, ‘Significant Events’ and clause  4.3 ‘Meters.’ 
Gaming Device operation may continue until critical data will be overwritten and lost.  
4.1.4.1 Comprehensive Checks  
Comprehensive checks of interface ele ment critical memory shall be made during each power 
resumption (this includes interface element restart).  
a) Upon resumption, the integrity of all interface element critical memory shall be checked.  
b) It is recommended that interface element critical memory is  continuously monitored for 
corruption or with comprehensive checks occurring at the start of game play.  
 c) In addition, it is recommended that the control program (software that operates the interface 
element’s functions) allow for the interface element to continually ensure the integrity of all 
control program components residing in non -volatile memory.  
4.1.4.2   Interface Element Requirements for Offline  
4.1.4.2.1  Ticketing Support   
It is recommended that the following set of minimum requirements should  be met for an Interface 
Element to be capable of providing validation information to an EGD for the issuance of offline 
vouchers after a loss of communication to the Ticket/Voucher Validation System has been identified . 
The Interface Element is recommende d to be capable of communicating to the game that offline 
voucher issuance is supported and allow the game to negotiate non -support of this feature.  
a) The Interface Element is recommended to meet the Manual Authentication ID requirements.  
b) The Interface Eleme nt is recommended to limit the number of provided validation numbers 
and seed, key, etc. values used for the issuance of offline vouchers to a max of 25 unused 
pairs.  
c) The Interface Element shall not provide to an EGD anymore than 25 validation numbers and 
seed, key, etc. values allowed for the issuance of offline vouchers until all outstanding offline 
voucher information has been fully communicated to the  Ticket/Voucher Validation System.  DUS 2580: 2022  
4 © UNBS yyyy – All rights reserved  
 d) The Interface Element is recommended to set a maximum expiration len gth of no more than 
30  gaming days for all provided and still unused validation numbers and seed, key, etc. 
values.  
e) Expired validation numbers and seed, key, etc. values shall be discarded in a way that 
prevents the re -use of unique combinations of va lidation numbers and seed, key, etc. values 
for a sufficient period of time on the system.  
4.1.5 Address Requirements.   
The interface element shall allow for the association of a unique identification number to be used in 
conjunction with a Gaming Device file on the MCS. This identification number will be used by the 
MCS to track all mandatory information of the associated Gaming Device.  Additionally, the MCS 
should not allow for duplicate Gaming Device file entry of this identification number.  
4.1.6 Configuration Access Requirements.   
The interface element setup/configuration menu(s) shall be not be available unless using an 
authorized access method.  
4.2 Front End Controller and Data Collector Requirements  
4.2.1 General Statement.   
A MCS may possess a Front End Processor (FEP) that gathers and relays all data from the 
connected Data Collectors to the associated database(s).  The Data Collectors, in turn, collect all 
data from connected Gaming Devices. Communication between components shall be via an 
approved method and at a minimum conform to the Communication Protocol requirements stated in 
Section 3.1 of this document. If the FEP maintains buffered/logging information, then a means shall 
exist which prevents the loss of critical information contained h erein.  
4.3 Server and Database Requirements  
4.3.1  General Statement.  A MCS will possess a Server(s), networked system or distributed 
systems that direct overall operation and an associated database(s) that stores all entered and 
collected system informa tion.  
4.3.2 System Clock.   
A MCS shall maintain an internal clock that reflects the current time (24hr format - which is 
understood by the local date/time format) and date that shall be used to provide for the following:  
a. Time stamping of Significant Eve nts; 
b. Reference clock for reporting; and  
c. Time stamping of configuration changes.  
4.3.3 Synchronization Feature.  
If multiple clocks are supported the MCS shall have a facility whereby it is able to update those 
clocks in MCS components, whereby conflicting information could occur.  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  5 
 4.3.4 Database Access.   
The MCS shall have no built -in facility whereby a casino user/operator can bypass system auditing 
to modify the database directly.  Casino Operators will maintain secure access control.   
4.4 Workstation Re quirements  
4.4.1 Jackpot/Fill Functionality.   
A MCS System shall have an application or facility that captures and processes every hand pay message 
from each Gaming Device. Hand pay messages shall be created for single wins (jackpots), progressive 
jackpot s and accumulated credit cash outs (canceled credits), which result in hand pays. A Fill (deposit of a 
pre-determined, or otherwise properly authorized, token amount in a Gaming Device’s hopper) is normally 
initiated from a hopper empty message while a Cre dit (removal of excess tokens from a Gaming Device) is 
normally user initiated. An allowable exception to fill initiation would be where the system provides 
preventative or maintenance fill functionality, in which the transaction may be initiated by the sy stem or an 
authorized user. Once captured, there shall be adequate access controls to allow for authorization, alteration, 
or deletion of any of the values prior to payment or execution.  
4.4.2 Tax Reporting Th reshold  
Every single win event hand pay message  confirmed at this application by personnel of proper authorization, 
equal to or greater than the tax reporting threshold) to be processed, either via the MCS or manually.  This 
option shall not be capable of being overridden.  The keyed reset ability to r eturn winnings from a taxable 
event to a Gaming Device should require user intervention to void the original jackpot slip that is generated.  
4.4.3 Jackpot/Fill Slip Information.    
The following information is required for all slips generated with some/al l fields to be completed by the MCS:  
a. Type of slip;  
b. Numeric Slip identifier (which increments per event);  
c. Date and Time (Shift if required) ;  
d. Gaming Device number; Denomination ; 
e. Amount of Fill;  
f. Amounts of Jackpot, Accumulated Credit, and Additional Pay;  
g. Additional Payout, if applicable;  
h. Total before taxes and taxes withheld,  if applicable;  
i. Amount to Patron;  
j. Total coins played and game outcome of award;  
k. Soft meter readings; and  DUS 2580: 2022  
6 © UNBS yyyy – All rights reserved  
 l. Relevant signatures as required by Gaming Board.  
 
Note: Items ‘b’ through ‘f,’ ‘l ,’ and ‘m’ apply to fill slips and items ‘b’ through ‘e’ and ‘g’ through ‘m’ 
apply to jackpot slips.   
4.4.4 Surveillance/Security Functionality.   
A MCS shall provide an interrogation program that enables on -line comprehensive searching of the 
significant  event log for the present and for the previous 14 days through archived data or 
restoration from backup where maintaining such data on a live database is deemed inappropriate. 
The interrogation program shall have the ability to perform a search based at l east on the following:  
a. Date and Time range;  
b. Unique interface element/Gaming Device identification number; and  
c. Significant event number/identifier.  
4.4.5 Gaming Device Management Functionality.   
A MCS shall have a master “Slot file” which is a database of  every Gaming Device in operation, including at 
minimum the following information for each entry. If the MCS retrieves any of these parameters directly from 
the Gaming Device, sufficient controls shall be in place to ensure accuracy of the information.  
a. Unique interface element/location identification number;  
b. Gaming Device identification number as assigned by the casino;  
c. Denomination of the Gaming Device (please note that the denomination may reflect an alternative 
value, in the case of a multi -denomination  game);  
d. Theoretical hold of the Gaming Device; and  
e. Control program(s) within Gaming Device.  
4.4.6 Accounting Functionality.   
A MCS shall have an application or facility that allows controlled access to all accounting (financial) 
information and shall be a ble to create all mandatory reports in the ‘Reporting Requirements,’ 
Section 3.4, as well as all Internal Control required reports, if specified.  
4.4.7 Exclusions. Generally, any system (component) not specified in this document that impacts 
revenue report ing shall be submitted to the laboratory for test. For example,  
Standalone Player Tracking Systems are not required for submission unless their function includes 
embedded feature(s) that affect revenue. (However, they may be tested for operation and versio n 
control if an integrated feature of a MCS submission.)  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  7 
 5. System  Requirements  
5.1 Communication Protocol  
5.1.1 General Statement.  The system shall support a defined communication protocol(s) and 
function as indicated by the communication protocol(s). A MCS shall provide for the following:  
a) All critical data communication shall be protocol based and/or incorporate an error detection 
and correction scheme to ensure an accuracy of ninety -nine percent (99%) or better of messages 
received;  
b) All critical data communication that may affect revenue and is unsecured either in transmission 
or implementation shall employ encryption. The encryption algorithm shall employ variable keys, or 
similar methodology to preserve secure communication; and  
c) All communica tion performed within the system, in it’s entirety, shall accurately function as 
indicated by the communication protocol that is implemented.  
5.2 Significant Events  
5.2.1 General Statement.  Significant events are generated by a Gaming Device and sent via the 
interface element to the MCS utilizing an approved communication protocol. Each event shall be 
stored in a database(s), which includes the following:  
a) Date and time which the event occurred; and  
b) Identity of the Gaming Device that generated the ev ent; and  
c) A unique number/code that defines the event; or  
d) A brief text that describes the event in the local language.  
5.2.2 Significant Events. The following significant events shall be collected from the Gaming Device 
and transmitted to the system f or storage:  
a) Power Resets or power failure;  
b) Hand pay Conditions (amount needs to be sent to the system):  
i. Gaming Device Jackpot (An award in excess of  the single win limit of the Gaming Device);  
ii. Cancelled Credit Hand pay; and  
iii. Progressive J ackpot (As per Jackpot above.)  
c) Door Openings (any door that accesses a critical area on the Gaming Device). Door switches 
(discrete inputs to the interface element) are acceptable if their operation does not result in 
redundant or confusing messaging.  
d) Coin or Token -In errors (It is acceptable to report Coin -In Jam, Reverse Coin -In and Coin Too 
Slow as a generic “Coin -In Error”):  DUS 2580: 2022  
8 © UNBS yyyy – All rights reserved  
 e) Bill (Item) Validator Errors (‘i’ and ‘ii’ should be sent as a unique message, if supported by the 
communication protoco l): 
i. Stacker Full (it is recommended that an explicit “stacker full” error message not be utilized 
since this may promote a security issue, rather “Bill Validator Malfunction” or equivalent); and  
ii. Bill (Item) Jam.  
f) Gaming Device Low RAM Battery Erro r; 
g) Reel Spin Errors (if applicable with individual reel number identified);  
h) Coin or Token -Out Errors (should be sent as unique messages if supported in the protocol):  
i. hopper jams;  
ii. hopper runaways or extra coins paid out; and  
iii. hopper empti es. 
i) Printer Errors (if printer supported):  
i. Printer Empty/Paper Low; and  
ii. Printer Disconnect/Failure.  
5.2.3  Priority Events.  
The following significant events shall be conveyed to the MCS where a mechanism shall exist for 
timely notification (it is  permissible for the following significant events to be sent to the system as a 
generic error code) in cases where the game is unable to distinguish the specifics of the event:  
a) Loss of Communication with Interface element;  
b) Loss of Communication with Gaming Device;  
c) Memory  corruption of the Interface element, if storing critical information; and  
d) RAM corruption of the Gaming Device.  
5.3 Meters  
5.3.1  General Statement  
Metering information is generated on a Gaming Device and collected by the interf ace element and 
sent to the MCS via a communication protocol. This information may be either read directly from the 
Gaming Device or relayed using a delta function.  Metering information on the MCS shall be labeled 
so they can be clearly understood in acco rdance to their function.  
5.3.2 Required Meters.   DUS 2580: 2022  
© UNBS yyyy – All rights reserved  9 
 The following metering information shall be communicated from the Gaming Device and stored on 
the system in units equal to the denomination of the gaming device or in dollars and cents:  
a) Coin In;  
i. The System shall maintain Paytable Coin -In and theoretical payback percentage information 
provided by the gaming device for each multi -game or multi -denomination/multi -game.  
ii. The System shall maintain Paytable Coin -In and weighted average theoretical paybac k 
percentage information provided by each gaming device which contain paytables with a difference 
in theoretical payback percentage which exceeds 4 percent between wager categories.  
b) Coin Out:  
c) Total Coin -Drop (coins -dropped or total value of all coins , bills and ticket/vouchers dropped);  
d) Attendant Paid Jackpots (hand -pays);  
e) Attendant Paid Cancelled Credits (if supported on Gaming Device);  
f) Physical Coin In  
g) Physical Coin Out  
h) Bills In (total monetary value of all bills accepted);  
i) Ticket/ Vouchers Out  
j) Machine Paid External Bonus Payout  
k) Attendant Paid External Bonus Payout  
l) Attendant Paid Progressive Payout  
m) Machine Paid Progressive Payout  
n) Ticket/Vouchers In (total monetary value of all ticket/vouchers accepted)  
Note: Please re fer to the standards for Gaming Devices for the electronic accounting meters that 
are to be maintained by the Gaming Device.  While these electronic accounting meters should be 
communicated directly from the Gaming Device to the MCS, it is acceptable to us e secondary MCS 
calculations where appropriate.  
5.3.3  Clearing Meters.  
An interface element should not have a mechanism whereby an unauthorized user can cause the 
loss of stored accounting meter information, see also Section 3.1.4 ‘Information Buffering.’   
5.4 Reporting Requirements  DUS 2580: 2022  
10 © UNBS yyyy – All rights reserved  
 5.4.1 General Statement.  Significant event and metering information is stored on the MCS in a 
database and accounting reports are subsequently generated by querying the stored information.  
5.4.2 Required Reports.  Reports wil l be generated on a schedule determined by the Gaming 
Commission, which typically consists of daily, monthly, yearly period, and life to date reports 
generated from stored database information. These reports at minimum will consist of the following:  
a) Net Win/Revenue Report for each Gaming Device;  
b) Drop Comparison Reports for each medium dropped (examples = coins, bills) with dollar and 
percent variances for each medium and aggregate for each type;  
c) Metered vs. Actual Jackpot comparison Report with the  dollar and percent variances for each 
and aggregate;  
d) Theoretical Hold vs. Actual Hold comparison with variances;  
e) Significant Event Log for each Gaming Device; and  
f) Other Reports, as required by individual jurisdictions.  
Note: It is acceptable to combine reporting data where appropriate (e.g., revenue, theoretical/actual 
comparison)  
Note: For additional revenue reporting requirements when ticket/voucher drop Gaming Devices are 
interfaced, please see ‘Ticket/ -Validation System Requirements,’ section  4.0 of this document.  
5.5 Security Requirements  
5.5.1  Access Control.   
The MCS shall support either a hierarchical role structure whereby user and password define 
program or individual menu item access or logon  program/device security based strictly on user 
and password or PIN. In addition, the MCS shall not permit the alteration of any significant log 
information communicated from the Gaming Device. Additionally, there should be a provision for 
system administrator notification and user lockout or audit  trail entry, after a set number of 
unsuccessful login attempts.  
5.5.2   Data Alteration.   
The MCS shall not permit the alteration of any accounting or significant event log information that 
was properly communicated from the Gaming Device without supervis ed access controls.  In the 
event financial data is changed, an automated audit log shall be capable of being produced to 
document:  
a) Data element  altered;  
b) Data element  value prior to alteration;  
c) Data element  value after alteration;  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  11 
 d) Time and D ate of alteration; and  
e) Personnel that performed alteration (user login).  
5.6 Additional System Features  
5.6.1  Gaming Device Program  
5.6.1.1  Verification Requirements  
If supported, a MCS may provide this redundant functionality to check Gaming Device ga me 
software. Although the overhead involved can potentially impede Gaming Device and MCS 
operation, the following information shall be reviewed for validity prior to implementation:  
a) Software signature algorithm(s); and  
b) Data communications error chec k algorithm(s).  
5.6.2   Verification Algorithm Timing  
 Verification may be user initiated or triggered by specific significant event(s) on the Gaming Device. 
To ensure complete coverage verification should be performed after each of the following events:  
a) Gaming Device Power Up; and  
b) New Gaming Device installed.  
5.6.3  FLASH Download Requirements  
 If supported, a MCS may utilize FLASH technology to update interface element software if all of the 
following requirements are met:  
a) FLASH Download functiona lity shall be, at a minimum, password protected, and should be at a 
supervisor level. The MCS can continue to locate and verify versions currently running but it cannot 
load code that is not currently running on the system without user intervention;  
b) An audit log shall record the time/date of a FLASH download and some provision shall be 
made to associate this log with, which version(s) of code was downloaded, and the user who 
initiated the download. A separate FLASH Audit Log Report would be ideal; and  
c) All modifications to the download executable or flash file(s) shall be submitted to the test 
laboratory for approval.  At this time, the test laboratory will perform a FLASH download to the 
system existing at the test laboratory and verify operation. The  test laboratory will then assign 
signatures to any relevant executable code and flash file(s) that can be verified by a regulator in the 
field. Additionally, all flash files shall be available to a regulator to verify the signature.  
Note: The above refers  to loading of new system executable code only. Other program parameters 
may be updated as long as the process is securely controlled and subject to audit.  
5.6.4  Remote Access Requirements.  DUS 2580: 2022  
12 © UNBS yyyy – All rights reserved  
 If supported, a MCS may utilize password controlled remote acces s to a MCS as long as the 
following requirements are met:  
a) Remote Access User Activity log is maintained depicting logon name, time/date, duration, 
activity while logged in;    
b) No unauthorized remote user administration functionality (adding users, ch anging permissions, 
etc.);  
c) No unauthorized access to database other than information retrieval using existing functions;  
d) No unauthorized access to operating system; and  
e) If remote access is to be continuous basis then a network filter (firewall) s hould be installed to 
protect access.  
Note: The MCS manufacturer may, as needed, remotely access the MCS and its associated 
components for the purpose of product and user support.  This feature however, shall be optional, 
by a secure means.  
5.6.5 Verificat ion of System Software  
System software components/modules shall be verifiable by a secure means (as defined in 3.5.1 
Access Controls) at the system level denoting Program ID and Version.  The system shall have the 
ability to allow for an independent integr ity check of the components/modules from an outside 
source and is required for all control programs that may affect the integrity of the system.  This shall 
be accomplished by being authenticated by a third -party device, which may be embedded within the 
system software or having an interface port for a third -party device to authenticate the media.  This 
integrity check will provide a means for field verification of the system components/modules to 
identify and validate the programs/files. The test laborator y, prior to system approval, shall approve 
the integrity check method.  
Note: If the authentication program is contained within the system software, the manufacturer shall 
receive written approval from the test laboratory prior to submission.  
5.7 Backups an d Recovery  
5.7.1 General Statement  
The MCS shall have sufficient redundancy and modularity so that if any single component or part of 
a component fails, gaming can continue. There shall be redundant copies of each log file or system 
database or both on the  MCS with open support for backups and restoration.  
5.7.2   Recovery Requirements.    
In the event of a catastrophic failure when the MCS cannot be restarted in any other way, it shall be 
possible to reload the system from the last viable backup point and f ully recover the contents of that 
backup, recommended to consist of at least the following information:  
a) Significant Events;  
b) Accounting information;  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  13 
 c) Auditing information;  
d) Specific site information such as slot file, employee file, progressive se t-up, etc; and  
e) If voucher issuance is supported, all information utilized in the voucher redemption process 
including information specific to the redemption of offline vouchers if applicable.  
6.  Ticket/voucher validation system requirements   
6.1 Gener al Statement.   
A ticket/voucher validation system may be entirely integrated into a MCS or exist as an entirely separate 
entity. Ticket/Voucher validation systems are generally classified into two types: bi -directional ticket/voucher 
systems that allow Ga ming Devices to print and redeem ticket/vouchers (TITO) and ticket/voucher out (TOO) 
only systems that allow Gaming Devices to print ticket/vouchers but do not allow ticket/voucher redemption.  
This chapter primarily addresses bi -directional ticket/voucher  systems.  Where ticket/voucher out only systems 
are utilized, some of the following may not apply.  
6.2 Payment by Ticket/Voucher Printer  
Payment by ticket/voucher printer as a method of credit redemption on a Gaming Device is only permissible 
when the Gam ing Device is linked to an approved validation system or MCS that allows validation of the 
printed ticket/voucher.  Validation information shall come from the validation system or MCS using a secure 
communication protocol.  
Note: For support of offline vou cher issuance, the Gaming Device shall be linked to an approved validation 
system or MCS that allows validation of the printed ticket/voucher, but does not have to be in constant 
communication for the issuance of voucher to be permissible.  
6.2 Ticket/Vouch er Issuance  
6.2.1  Ticket/Voucher Information used by the Gaming Device while communicating to a validation system.  
The ticket/voucher validation system shall be able to communicate the following ticket/voucher data to the 
Gaming Device to print on the ti cket/voucher.  
a) Casino Name/Site Identifier;  
b) Indication of an expiration period from date of issuance, or date and time the ticket/voucher will expire (24 
hr format which is understood by the local date/time format) if applicable;  
c) System date and ti me (24 hr format which is understood by the local date/time format); and  
d) Ticket/Voucher  validation number for the Gaming Device to generate the validation number.  
6.2.2 Algorithm for generating ticket/voucher validation numbers or seeds.  
a) System Vali dation – the algorithm or method used by the validation system or MCS to generate the 
ticket/voucher validation number shall guarantee an insignificant percentage of repetitive validation numbers.  
b) Gaming Device generated validation number (system seed)  – The validation system shall send a unique 
seed to the Gaming Device upon enrolling the Gaming Device as ticket/voucher printing capable.  The system 
may subsequently send a new seed to the Gaming Device after a ticket/voucher is printed.  The algorithm or 
methods used to determine the seed shall guarantee an insignificant percentage of repetitive validation 
numbers.  DUS 2580: 2022  
14 © UNBS yyyy – All rights reserved  
 6.2.2.1  Algorithm for generating offline ticket/voucher authentication identifiers   
If support, the offline authentication identifier shall be of a unique value that is derived by a HASH or other 
secure encryption method of at least 128 bits, that will: uniquely identify the wager instrument, verify that the 
redeeming system was also the issuing system, and validate the amount of the voucher . The following 
minimum set of inputs shall be used to create the authentication identifier:  
a) EGM identifier;  
b) Validation number;  
c) Voucher amount; and  
d) Secure seed, key, etc. provided by the validation system or MCS to the Gaming Device;  
i. Secure seeds, keys, etc. as assigned shall be sufficiently random.  Measures to avoid predictability will 
be reviewed by the test laboratory on a case by case basis.  
ii. The minimum length for any secure seeds, keys, etc. employed by the validation system or MCS shall be 
chosen from a pool of the variable type specified by the communication protocol utilized. The pool shall be 
comprised of at least 10 to the power of 14 randomly distributed values.  
6.2.3 System Ticket/Voucher Records.  
a) The validation system shall retrieve the ticket/voucher information correctly based on the secure 
communication protocol implemented, and store the ticket/voucher information into a database.  
b) The ticket/voucher record on the host system shall contain at a minimum the following t icket/voucher 
information:  
i. Validation number;  
ii. Date and time the Gaming Device printed the ticket/voucher (24 hr format which is understood by the 
local date/time format);  
iii. Type of transaction or other method of differentiating ticket/voucher typ es (assuming multiple 
ticket/voucher types are available);  
iv. Numeric value of ticket/voucher in dollars and cents;  
v. Status of ticket/voucher (i.e. valid, unredeemed, pending, void, invalid, redemption in progress, 
redeemed, etc.);  
vi. Date and time the  ticket/voucher will expire (24 hr format which is understood by the local date/time 
format or expiration period from date of issuance) if applicable;  
vii. Machine number (or Cashier/Change booth location number, if ticket/voucher creation outside the 
Gami ng Device is supported) that identifies where the ticket/voucher was issued from.  
6.2.4 System Requirements for Offline Ticketing Support.   
This clause  is recommended if an approved offline voucher routine is supported.  
a) Support the identification and r edemption of offline vouchers through a system provided application.  
b) Log all access and operations of users of the aforementioned application for 14 days through archived 
data or restoration from backup where maintaining such data on a live database is deemed inappropriate.  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  15 
 c) The validation system or MCS shall set a maximum expiration length of no more than 30 gaming days for 
all provided and still unused validation numbers and seed, key, etc. values.  
d) Expired validation numbers and seed, key, etc. v alues shall be discarded in a way that prevents the re -
use of unique combinations of validation numbers and seed, key, etc. values for a sufficient period of time on 
the system.  
6.2.5 Ticket/Voucher Printing during loss of commu nication with validation sys tem 
For validation systems that communicate to a Gaming Device through an Interface Board (also called SMIB, 
System Machine Interface Board), if any links between the Interface Board and the MCS database go down, 
the Interface Board shall: 
a) Not respond t o the validation request from the Gaming Device and stop ticket/voucher printing, or  
b) Prevent the Gaming Device from further ticket/voucher issuance, or  
c) Not read or store any further ticket/voucher information generated by the Gaming Device.  
Note: A maximum of 2 (two) ticket/vouchers directly after loss of communication is acceptable, in cases where 
the interface element has already been ‘seeded’ by the system, provided the ticket/voucher issuance 
information is sent immediately, when communication is reestablished.  
NOTE : This section does not apply to systems employing an approved offline voucher routine.  
6.3 Ticket/Voucher Redemption  
6.3.1 Online Ticket/Voucher Redemption.   
Ticket/Vouchers can be redeemed at Gaming Device, Cashier/Change booths or ot her approved Validation 
Terminals (Kiosks) provided they are enrolled for ticket/voucher validation with a validation system. (See 
Standards for Gaming Devices  for Gaming Device ticket/voucher validation requirements).  
a) The validation system shall proce ss ticket/voucher redemption correctly according to the secure 
communication protocol implemented;  
b) The validation system shall update the ticket/voucher status on the database during each phase of the 
redemption process accordingly.  In other words, whe never the ticket/voucher status changes, the system 
shall update the database; Upon each status change, the database shall indicate the following information:  
i. Date and time of status change;  
ii. Ticket/Voucher status;  
iii. Ticket/Voucher value;  
iv. Mach ine number or source identification from where the ticket/voucher information came from.  
6.3.2  Offline Ticket/Voucher Redemption  
If supported, Offline Ticket/Vouchers can be redeemed at Cashier/Change booth provided they are enrolled 
for ticket/voucher va lidation with a validation system.  
a) The validation system at a minimum shall support the identification and redemption of offline vouchers 
through a system provided application;  
b) The validation system shall process offline ticket/voucher redemption cor rectly according to the secure 
communication protocol implemented;  DUS 2580: 2022  
16 © UNBS yyyy – All rights reserved  
 c) The validation system shall update the ticket/voucher status on the database during each phase of the 
redemption process accordingly.  In other words, whenever the ticket/voucher status changes, the system 
shall update the database. Upon each status change, the database shall indicate the following information:  
i. Date and time of status change;  
ii. Ticket/Voucher status;  
iii. Ticket/Voucher value;  
iv. Machine number or source identifica tion from where the ticket/voucher information came from.  
6.3.3 Cashier/Change Booth Operation  
All validation terminals shall be user and password controlled. Once presented for redemption, the cashier 
shall:  
a) Scan the bar code via an optical reader or e quivalent; or  
b) Input the ticket/voucher validation number manually; and  
c) May print a validation receipt, after the ticket/voucher is electronically validated, if applicable.   
6.3.4 Validation Receipt Information   
If applicable, the validation receipt,  at a minimum, shall contain the following printed information:  
a) Machine number;  
b) Validation number;  
c) Date and Time paid;   
d) Amount; and  
e) Cashier/Change Booth identifier.  
6.3.5 Invalid Ticket/Voucher Notification.  
The validation system or MCS shall have the ability to identify these occurrences and notify the cashier that 
one of the following conditions exists:  
a) Ticket/Voucher cannot be found on file (stale date, forgery, etc.);  
b) Ticket/Voucher has already been paid; or  
c) Amount of ticket/vo ucher differs from amount on file (requirement can be met by display of ticket/voucher 
amount for confirmation by cashier during the redemption process).  
6.3.6 **Ticket/Voucher Redempt ion During Communication Loss  
If the on -line data system temporarily goe s down and validation information cannot be sent to the validation 
system or MCS, an alternate method of payment shall be provided either by the validation system possessing 
unique features, (e.g., validity checking of ticket/voucher information in conjunc tion with a local database 
storage), to identify duplicate ticket/vouchers and prevent fraud by reprinting and redeeming a ticket/voucher 
that was previously issued by the Gaming Device;  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  17 
 Note: A maximum of 2 (two) ticket/vouchers directly after loss of co mmunication is acceptable, in cases where 
the interface element has already been ‘seeded’ by the system, provided the ticket/voucher issuance 
information is sent immediately, when communication is reestablished.  
Note: This section does not apply to system s employing an approved offline voucher routine.  
6.3.7 Redemption Terminals (Kiosks)  
Refer to the Standards for Redemption Terminals for technical standards for these devices.  
6.4 Reports  
6.4.1  Reporting Requirements  
The following reports shall be generate d at a minimum and reconciled with all validated/redeemed 
ticket/vouchers:  
a) Ticket/Voucher Issuance Report;  
b) Ticket/Voucher Redemption Report;  
c) Ticket/Voucher Liability Report;  
d) Ticket/Voucher Drop Variance Report  
e) Transaction Detail Report shall be available from the validation system that shows all ticket/vouchers 
generated by a Gaming Device and all ticket/vouchers redeemed by the validation terminal or other Gaming 
Device; and  
f) Cashier Report, which is to detail individual ticket/vouchers,  the sum of the ticket/vouchers paid by 
Cashier/Change Booth or Redemption Terminal.  
Note: The requirements for ‘b’ & ‘d’ are waived where two -part ticket/vouchers exist for the Gaming Device 
where the first part is dispensed as an original ticket/voucher  to the patron and the second part remains 
attached to the printer mechanism as a copy (on a continuous roll) in the Gaming Device.  
6.5 Security  
6.5.1 Database and Validation Component Security  
Once the validation information is stored in the database, the  data may not be altered in any way. The 
validation system database shall be encrypted or password -protected and should possess a non -alterable 
user audit trail to prevent unauthorized access. Further, the normal operation of any device that holds 
ticket/v oucher information shall not have any options or method that may compromise ticket/voucher 
information. Any device that holds ticket/voucher information in its memory shall not allow removing of the 
information unless it has first transferred that informat ion to the database or other secured component(s) of 
the validation system.  
7.0 Environmental System and Safety requirements  
7.1 General Statement.   
This clause  govern s the environmental system and safety requirements for all system components submitted 
for review.  DUS 2580: 2022  
18 © UNBS yyyy – All rights reserved  
 7.2 Hardware and Player Safety  
7.2.1 General Statement.   
Electrical and mechanical parts and design principals of the electronic associated hardware may not subject a 
player to any physical hazards.  The test laboratory shall NOT make any findi ng with regard to Safety and 
EMC testing as that is the responsibility of the manufacturer of the goods or those that purchase the goods.  
Such Safety and EMC testing may be required under separate statute, regulation, law or Act and should be 
researched, accordingly, by those parties who manufacture or purchase said hardware.  The test laboratory 
shall not test for, be liable for, nor make a finding relating to these matters.  
7.3 Environmental Effects on System Integrity  
7.3.1  Integrity Standard  
The Labora tory will perform certain tests to determine whether or not outside influences affect game fairness 
to the player or create cheating opportunities.  An on -line system shall be able to withstand the following tests, 
resuming game play without operator inter vention:  
a) Electro -magnetic Interference.  Systems shall not create electronic noise that affects the integrity or 
fairness of the neighboring associated equipment;  
b) Electro -static Interference.  Protection against static discharges requires that the sy stem’s hardware be 
earthed in such a way that static discharge energy shall not damage or inhibit the normal operation of the 
electronics or other components within the System.  Systems may exhibit temporary disruption when 
subjected to a significant elect ro-static discharge greater than human body discharge, but they shall exhibit a 
capacity to recover and complete any interrupted function without loss or corruption of any control or data 
information associated with the System. The tests will be conducted with a severity level of up to 27KV air 
discharge.  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  19 
 Annex  A 
(normative)  
 
Annex title  
A.1 General  
A.2 Clause  
A.2.1  Subclause (level  1) 
A.2.1.1  Subclause (level  2) 
A paragraph.  
A.2.1.1.1  Subclause (level  3) 
A paragraph.  
A.2.1.1.1.1  Subclause (level  4) 
A parag raph.  
A.2.1.1.1.2  Subclause (level  4) 
A paragraph.  
A.2.1.1.2  Subclause (level  3) 
A paragraph.  
A.2.1.2  Subclause (level  2) 
A paragraph.  
A.2.2  Subclause (level  1) 
A paragraph.  
A.3 Clause  
A.3.1  A level  1 subclause without a title.  
A.3.1.1  A level  2 subclause without a title.  
A.3.1.1.1  A level  3 subclause without a title.  
A.3.1.1.1.1  A level  4 subclause without a title.  DUS 2580: 2022  
20 © UNBS yyyy – All rights reserved  
 A.3.1.1.1.2  A level  4 subclause without a title.  
A.3.1.1.2  A level  3 subclause without a title.  
A.3.1.2  A level  2 subclause without a title.  
A.3.2 A level  1 subclause without a title.  DUS 2580: 2022  
© UNBS yyyy – All rights reserved  21 
 Annex  B 
(informative)  
 
Which styles correspond to which element  — Quick reference guide  
Element  Style name  a 
Any element of text for which the correct style to use is not known with certainty or 
for which no other style of the template is suitable  Special  
Annex  heading, status and title  ANNEX  
Bibliography  reference entry  bibliography  
 title zzBiblio  
Clause  body of document  Heading  1* 
 annexes  a2 
Definition  Definition  
Displayed mathematical 
and chemical formulae  formula  Formula  
variables list  dl 
Example  Example  
Figure  footnote  Figure footnote  
 note Note  
 title Figure title  
Figure footnote  Figure footnote  
Footnote  reference  Footnote Reference*  
 text Footnote Text*  
Foreword  text Foreword  
 title zzForeword  
Index  entry  Index 1*  
 entry heading  Index Heading*  
 “Index” title  zzIndex  
Introduction  text Normal*  
 title Introduction  
List ordered  level 1 List Number*  
  level 2 List Number  2* 
  level 3 List Number  3* 
  level 4 List Number  4* 
 unordered  level 1 List Continue*  
  level 2 List Continue  2* 
  level 3 List Continue  3* 
  level 4 List Continue  4* DUS 2580: 2022  
22 © UNBS yyyy – All rights reserved  
 Element  Style name  a 
Normative reference  cross -reference to a normative reference defined in the 
“Normative references” c lause  ExtXref  
in “Normative references” clause  RefNorm  
Note integrated in text, figures and tables  Note  
Paragraph  Normal*  
Subclause with title  annexes  level 1 a3 
  level 2 a4 
  level 3 a5 
  level 4 a6 
 body of text  level 1 Heading  2* 
  level 2 Heading  3* 
  level 3 Heading  4* 
  level 4 Heading  5* 
  level 5 Heading  6* 
Subclause without title  level 1 p2 
 level 2 p3 
 level 3 p4 
 level 4 p5 
 level 5 p6 
Table  note Note  
 table footnote  See Table footnote.  
 text 9 pt (recommended)  Table text (9 ) 
  8 pt, for large tables  Table text (8)  
  7 pt, for very large tables  Table text (7)  
  10 pt (not recommended)  Table text (10)  
 title Table title  
Table footnote  identification letter of the table footnote  TableFootNoteXref  
 reference  TableFootNoteX ref 
 text Table footnote  
Table of contents  “Contents” title  zzContents  
 entries  level 1 TOC  1* 
  level 2 TOC  2* 
  level 3 TOC  3* 
  level 4 TOC  4* 
  level 5 TOC  5* 
  level 6 TOC  6* 
  unnumbered elements  TOC  9* DUS 2580: 2022  
© UNBS yyyy – All rights reserved  23 
 Element  Style name  a 
Term  cross -reference to a term define d in the “Terms and 
definitions” clause  Defterms  
 in the “Terms and definitions” clause in a terminology 
document  Term(s)  
 reference number  TermNum  
a Style names marked with an asterisk are based on predefined Microsoft styles. These styles are recogniz ed by the 
various linguistic versions of Word and their names will be translated automatically into the language of the Word version 
which you are using. For these Microsoft styles, the user will need to derive the correspondence between the name displayed  
and that given in this table; for example, if the same document is opened using English and French versions of Word, text 
styled “Footnote Reference” in the English version is called “Appel de note” in the French version.  
 DUS 2580: 2022  
24 © UNBS yyyy – All rights reserved  
 Bibliography  
[1] ISO ##### -#, General title — Part #: Title of part  
[2] ISO ##### -##:20##, General title — Part ##: Title of part  
A Bibliography , if present, shall appear after the last annex. The drafting rules set out in ISO  690[11] shall be 
followed.  
The bibliography may include  
— documents that are not publicly available,  
— documents which are only cited in an informative manner, and  
— documents which have merely served as bibliographic or background material in the preparation of the 
document.  
For online referenced documents, info rmation sufficient to identify and locate the source shall be provided. 
Preferably, the primary source of the referenced document should be cited, in order to ensure traceability. 
Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The 
reference shall include the method of access to the referenced document and the full network address, with 
the same punctuation and use of upper case and lower case letters as given in the source (see ISO 690-2[12]). US nnnn -n: yyyy  
© UNBS yyyy – All rights reserved  25 
 Certification marking  
Products that conform to Uganda standards may be marked with Uganda National Bureau of Standards 
(UNBS) Certification Mark shown in the figure below.  
The use of the UNBS Certification Mark is governed by the Standards Act, and the Regul ations made 
thereunder. This mark can be used only by those licensed under the certification mark scheme operated by 
the Uganda National Bureau of Standards and in conjunction with the relevant Uganda Standard. The 
presence of this mark on a product or in relation to a product is an assurance that the goods comply with the 
requirements of that standard under a system of supervision, control and testing in accordance with the 
certification mark scheme of the Uganda National Bureau of Standards. UNBS marked p roducts are 
continually checked by UNBS for conformity to that standard.  
Further particulars of the terms and conditions of licensing may be obtained from the Director, Uganda 
National Bureau of Standards.  
 
 US nnnn -n: yyyy    
 
ICS nn.nnn.nn  
Price based on nn pages  
© UNBS yyyy– All rights reserved