Wireless M-Bus Documentation

Reference Manual

January 17, 2011

REFERENCES

page 2

References
[1] Communication systems for meters and remote reading of meters. Part 1: Data exchange; English version EN 13757-1, 2002. [2] Communication systems for meters and remote reading of meters. Part 2: Physical and link layer; English version EN 137572, 2004. [3] Communication systems for meters and remote reading of meters. Part 3: Dedicated application layer; English version EN 137573, 2004. [4] Communication systems for meters and remote reading of meters. Part 4: Wireless meter readout (Radio meter reading for operation in the 868 MHz to 870 MHz SRD band); German version EN 137574, 2005. [5] Communication systems for meters and remote reading of meters. Part 5: Wireless Relaying; English version prEN 13757-5, 2009. [6] Communication systems for meters and remote reading of meters. CEN TC 294. [7] Home and building electronic systems (hbes). CENELEC TC 205. [8] Telecontrol equipment and systems. Part 5: Transmission protocols; EN 870-5, 2002. [9] ftdi virtual com port drivers. http://www.ftdichip.com/Drivers/VCP .htm, 2009. [10] list of msp430 jtag adapters. http://www.ti.com/msp430, 2009. [11] elprotronic msp430 ashing tool. http://www.elprotronic.com/fetpro430.html, 2009. [12] Pan7550 testboard v1.1 user manual. http://www.ecom.panasonic.de/pdf/engl/164ext2.pdf, 2009. [13] Wireless m-bus stack and demo applications. http://www.stzedn.de/wireless-m-bus.html, 2010. [14] ez430-chronos development tool user manual. http://focus.ti.com/docs/toolsw/folders/print/ez430chronos.html, 2010. [15] Msp430fg4618/f2013 experimenters board user guide. http://focus.ti.com/lit/ug/slau213a/slau213a.pdf, 2010. [16] Java runtime environment. http://java.sun.com, 2010. [17] Open metering system specication volume 2: Primary communication.

https://www.zvei.org/leadmin/user_upload/Fachverbaende/Energietechnik/Brancheninformationen/OMS/OMSSpec_Vol2_Primary_v200.pdf, 2010.

[18] Dutch smart meter requirements - p2 companion standard. http://www.energiened.nl/_upload/bestellingen/publicaties/2 2010. [19] Implementation of a three-phase electronic watt-hour using the msp430f471xx.

http://focus.ti.com/lit/an/slaa409a/slaa409a.pdf.

Wireless M-Bus Documentation Version 1.0

SUMMARY

page 3

[20] Quick start guide to the smart meter reference design.

Summary

M-Bus is recognized in many regions of the world as a basis for new advanced metering infrastructure (AMI) installations. Their wireless implementation brings a competitive advantage; also they are products easy to install and maintain. The Wireless M-Bus standard (EN 13757-4:2005) denes the wireless communication between meters for water, gas, heat and electricity, and the data concentrators. The stzedn stack implements the protocols for Wireless M-Bus. It has demonstrated its interoperability with modules of well-known manufacturers on the different protocol layers and is compliant with the current Wireless M-Bus standard [4]. It is an optimised solution between small footprint and excellent modularity and scalability. This document describes a demonstration software based on the stzedn protocol stack for Wireless M-Bus.

Wireless M-Bus Documentation Version 1.0

CONTENTS

page 4

Contents
1 Summary 2 Wireless M-Bus Basics 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Communication Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Unidirectional vs. Bidirectional Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 6 7 7 7 9

2.3 Available Software Congurations and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Working with the different software congurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 Library interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.2 IDE Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.3 Libraries to include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.4 The hardware abstraction layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.5 API function calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.6 Watchdog handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3 Congurations 15

3.1 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 AT Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Additional tools and further options 16

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 capt2web Wireless M-Bus Monitoring and Commissioning Tool . . . . . . . . . . . . . . . . . . . . . . . . . 16

Wireless M-Bus Documentation Version 1.0

LIST OF TABLES

page 5

List of Tables
1 2 3 4 5 6 7 Operating Modes of Wireless M-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operating Modes of Wireless M-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compatibility matrix for Wireless M-Bus operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 8

Available Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Design parameter "Top layer" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Design parameter "device" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Design parameter "Mode" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 6

List of Figures
1 2 3 4 5 Bidirectional Communication Mode T2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Bidirectional Communication Mode S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Bidirectional Communication Mode R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Hardware for in-eld Wireless M-Bus data monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 capt2web Network Monitoring Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2
2.1

Wireless M-Bus Basics

Introduction

The Metering Bus (or in short "M-Bus ") is a eld bus, which is specialized for transmitting metering data from gas, heat, water or other meters to a data collector. It is described by European Norm (EN 13757), which includes the specication of wired and Wireless M-Bus. The specication is divided into ve parts: EN 13757-1 ([1]): Communication systems for meters and remote reading of meters - Part 1: Data exchange The rst part describes the basic communication between the meters and a central data collector. It provides an overview of the communication system. EN 13757-2 ([2]): Communication systems for meters and remote reading of meters - Part 2: Physical and link layer This part includes the specication of the physical data transmission using wired connections. It also includes the description of the protocol to transmit the data. EN 13757-3 ([3]): Communication systems for meters and remote reading of meters - Part 3: Dedicated application layer The third part of M-Bus describes an application protocol, which allows the data transmission of meters multivendor capability. So devices of different manufacturers may be combined in one system. EN 13757-4 ([4]): Communication systems for meters and remote reading of meters - Part 4: Wireless meter readout (Radio meter reading for operation in the 868 MHz to 870 MHz SRD band) This part species the wireless communication of M-Bus and is the main source document for this implementation. It includes the Physical and the Data Link Layer for wireless devices, and it corresponds to specication EN 13757-2 for wired communication. EN 13757-5 ([5]): Communication systems for meters and remote reading of meters - Part 5: Relaying This last part includes different proposals for relaying the meter data to overcome the range problem between

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 7

remote meters and data collectors. The sixth part of this norm relates only to wired busses and is disregarded in this document. All parts of EN 13757 are compilant to the European Norm EN 870-5 [8].

2.2
2.2.1

Protocol Stack
Introduction

M-Bus is compatible to the international ISO/OSI-model, but only the layers 1, 2 and 7 are implemented. Layer 7 Layer 2 Layer 1 Application Layer (EN 13757-3) Data Link Layer (EN 13757-2 or EN 13757-4) Physical Layer (EN 13757-2 or EN 13757-4) Table 1: Operating Modes of Wireless M-Bus

Up to now, the application layer implements all other protocol layers required for a specic appliance. Especially if routing is required according to [5], it resides on the application layer. This lack of modularity might be one reason why standardized routing algorithms are currently not available for Wireless M-Bus. But the reduced modularity leads to compact implementations running on very small devices with minimum computing ressources. The MBus favours asymmetric network topologies with low-cost or low-power metering devices on the one side and data collectors or gateways with higher performance on the other side. Currently, only point-to-point or star network topologies apply. Mesh networking is not possible, as the required routing algorithms are not specied yet. This chapter describes the settings for common implementations of the data collector and the metering devices to setup a network in star topology.

2.2.2

Communication Modes

Based on the appliance, there are combinations of communication modes for data collectors and metering devices. These settings dene the communication ow and the conguration of the radio channel. Table 2 lists available communication modes.

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 8

Mode S1

Communication Unidirectional

Description In the stationary mode, the metering devices send their data several times a day. In this mode, the data collector may save power as the metering devices send a wakeup signal before transmitting their data. Same as S1, but the data collector must not enter low-power mode. Bidirectional version of S1. In the Frequent Transmit mode, the metering devices periodically send their data to collectors in range. The interval is congurable in terms of several seconds or minutes. Bidirectional version of T1. The data collector may request dedicated data from the metering devices. The Frequent Receive mode permits multiple metering devices not to interfere due to frequency multiplexing. Table 2: Operating Modes of Wireless M-Bus

S1-m S2 T1

Unidirectional Bidirectional Unidirectional

T2 R2

Bidirectional Bidirectional

Table 3 lists the combinations of the communication modes of meters and data collectors. In T2 mode, the communication settings for the two data directions are different. Due to deviant requirements, both communication devices have to support fast switching of communication speed, coding scheme, and frequency. Metering Device Data Collector S1 S1-m S2 S1 X X X S1-m X X X S2 X X X T1 T2 R2 Tx radio settings 868,30 MHz 32.768 kcps Manchester enc. 868,30 MHz 32.768 kcps Manchester enc. 868,330 MHz 4.8 kcps Manchester enc.

T1 T2

X X

X X

R2

Table 3: Compatibility matrix for Wireless M-Bus operating modes

The table above shows that although the T- and S-modes cannot be combined, a T2 data collector may interfere with a parallel S-mode communication.

Wireless M-Bus Documentation Version 1.0

868,03MHz+n*60kHz 4,8 kcps Manchester encoding

868,30 MHz 32.768 kcps Manchester encoding

868,30 MHz 32.768 kcps Manchester encoding

868,30 MHz 32.768 kcps Manchester encoding

868,95 MHz 100 kcps 3-out-of-6 encoding

868,95 MHz 100 kcps 3-out-of-6 encoding

Metering Devices Tx radio settings

WIRELESS M-BUS BASICS

page 9

2.2.3

Unidirectional vs. Bidirectional Communication

If unidirectional communication is used, data is only sent from the metering device to the data collector. This enables simple transmitters as metering devices while the data collector only needs to receive. Becaus listen-beforetalk (LBT) and dynamic network conguration are not possible using unidirectional communication, it only applies for static communication with little load. In a bidirectional communication, there are three ways to exchange data between a meter device and a data collector: 1. meter device sends Access Demand Requests (AD Req) periodically to be detectable for data collectors. If a data collector wants to open a bidirectional communication channel, it sends an Acknowledgement (ACK) frame. When receiving an ACK, the meter device stops sending AD Req, and it waits for the data collector to send a User Data Request. The requested data are transmitted in a User Data Response packet, and the meter devices continues the periodical transmission of Access Demand Requests. This lean protocol requires little resources on the metering device. The communication ow, which applies in T2 communication mode, is illustrated in Fig. 1.

Figure 1: Bidirectional Communication Mode T2

2. It is also possible that the meter device sends its meter data periodically. This is the case in mode S2. In this mode, a bidirectional communication will only be established if further data or commands needs to be exchanged (cf. Fig. 2). After the channel setup, the communication is identical to case 1. Fig. 2 shows a usual communication ow.
Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 10

Figure 2: Bidirectional Communication Mode S2

3. In R2 mode, the meter device is listening periodically for a waking preamble sent within a request packet. If such a request has been received, the channel will be established according to case 1 (mode T2). If no communication is required, the meter device enters sleeping mode. Therefore, the data collector has to know the approximate time, when the meter device enters listening mode, and it has to send the wakeup packets several times if the meter device does not respond. Figure 3 shows an example communication ow in R2 mode.

Figure 3: Bidirectional Communication Mode R2

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 11

2.3

Available Software Congurations and Documentation

The demonstration application demonstrates only a few possibilities of the complete stack functionality. For instance, the stack can be used like a modem that serially connects to the customers application. An AT command set is used to set up and run the Wireless M-Bus network. In this case, programming the module is not necessary since the device is precongured. A binary non-readable command set is also available to minimize the communication overhead. If the stack is used as modem, it is exclusively used for communication tasks. For applications that are sensitive e.g. concerning the energy consumption or cost, often only one microcontroller is used for both: The communication and the sensor application. In these cases, the protocol stack can be purchased as library or as source code in different software packages. Please contact metering@stzedn.de for a quotation. Refer to Table 4 for a list of available software packages. Customizations of the stack as well as customer specic applications are possible upon request. Software Demo application (binary le) Conguration software (PC) AT parser application (binary le) Conguration software (PC) Application layer, data link layer, and physical layer (library) Example user application (source code) Conguration software (PC) Data link layer and physical layer (library) Application layer (source code) Example user application (source code) Conguration software (PC) Complete protocol stack (source code) Example user application (source code) Conguration software (PC) Documentation Demo application Conguration software AT command set description Conguration software Application description layer API Wireless M-Bus modem application based on the application layer or the data link layer Implementation of a standard Wireless M-Bus data collector and metering device Purpose Commissioning tests, simple trafc generator

User application (documented source code) Conguration software Data link layer and physical layer - API description Application layer - API description User application (documented source code) Conguration software Fully documented source code All API descriptions (additional document) Conguration software Table 4: Available Software Packages Wireless M-Bus data collector and metering device with custom application layer to be used e.g. together with an existing application layer for wired M-Bus

Source code portable to other C platforms and custom hardware, optimization for the application

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 12

2.4

Working with the different software congurations

As shown in Table 4, Multiple approaches exist when using the protocol stack. 1. Verify the devices: Prior to the development of custom applications, the hardware should be checked to work properly using the demo application. Monitoring the radio communication helps not only during the rst steps of wireless networking. Amongst others, chapter 4.2 presents a sniffer tool for Wireless M-Bus. 2. Using the device as a modem: In the modem-like congurations, a dedicated M-Bus rmware is loaded to the radio board as integral binary le. No custom rmware is runnning on the radio board, but the radio communication is controlled using a serial interface. An AT command set known from modems eases the conguration. The chapters 3.1 and 3.2 are for reference purpose only. They contain the description of the functions called by the library, and they can be omitted if the relevant standards are at hand. Chapter 3.3 explains the AT parsers structure and commands. For each specic command, the cross reference to the concerning library functions is provided. Start from this chapter when running the radio board as a modem. By default, the hardware modules are shipped with a modem application so that no debug adaptor is required to run the devices. This rmware even contains the test modes required for radio equipment certication. 3. Using the library for the communication: Using this approach requires a professional license of an Integrated Development Environment (IDE) to compile and run the rmware. As the library provides an abstraction layer for the radio communication and parts of the hardware functionality, please continue with the following sections for correctly using the library funtionality.

2.5
2.5.1

Library interaction
Introduction

This chapter informs about the different libraries and the opportunities to include them into custom rmware. Example projects for the most common Integrated Development Environments (IDE) shall help to congure the devices correctly for the network application.

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 13

2.5.2

IDE Projects

The software will be shipped including project les for the following IDEs: IAR Embedded Workbench for MSP430 Code Composer Essentials (CCE) The project les provide a fully pre-congured demo-application-environment for building a demo application accessing the appropriate stack-library. The structure of the source le directory should not be modied, as long as the IDE project les are not adapted accordingly to the modications. The structure of the directory containing the source les looks like this: Demo Application Meter app_demo_apl_meter.c app_demo_dll_meter.c Collector app_demo_apl_collector.c app_demo_dll_collector.c Wireless M-Bus Includes applicationlayer_api.h datalinklayer_api.h hal_api.h Libraries (The delivered libraries depend on the license) wmbus_lib_apl.r43/.lib wmbus_lib_dll.r43/.lib wmbus_lib_.... .r43/.lib For rst steps on hardware, the IDE needs to be congured for usage of the appropriate debugger!

Wireless M-Bus Documentation Version 1.0

WIRELESS M-BUS BASICS

page 14

2.5.3

Libraries to include

In order to save resources and to increase the performance of the application the stack is available in several libraries. The choice of a suitable library depends on the application and the requirements. There are three design parameters composing the required library: Design parameter "Top layer" APL DLL Description The stack includes all layers and can be accessed via "apl_-functions". The stack includes all layers up to the datalink layer (no application layer) and can only be accessed via "dll_-functions". Table 5: Design parameter "Top layer"

Design parameter "device" Meter Collector both

Description The stack only includes functionality for meter devices The stack only includes functionality for collector devices Functionality of the stack includes meter and collector devices and may be chosen during runtime (requires more resources). Table 6: Design parameter "device"

Design parameter "Mode" S1/S1-m/S2/T1/T2/R2 all

Description The stack uses either the S1, S1-m, S2, T1, T2 or R2 mode for transmission/reception. The mode to be used by the stack may be chosen during runtime (requires more resources). Table 7: Design parameter "Mode"

2.5.4

The hardware abstraction layer

The stack uses a slight HAL which covers the hardware resources required by the stack. This is to avoid crashing the stack due to misconguration of required resources. The resources required by the stack are: One timer (ms resolution). The appropriate pins in order to access an externally connected transceiver. Access to an exclusive non-volatile data memory (e.g. info ash in case of TIs MSP430-series, EEPROM, ...) The following approach is strongly recommended in order to avoid crashing the stack: First of all it is recommended to read the API documentation of the HAL before accessing periphals of the microcontroller. This is to verify, if the appropriate hardware/periphery is already abstracted by the HAL. In case it is abstracted, it is strongly recommended to use the API function in order to avoid an unpredictable behaviour of the stack! In case the periphery is not mentioned within the API documentation, it is safe to directly access the peripherals as documented by the microcontroller manufacturer.

Wireless M-Bus Documentation Version 1.0

CONFIGURATIONS

page 15

2.5.5

API function calls

The libraries are shipped with some header les. However, the following two header les must be included: applicationlayer_api.h resp. datalinklayer_api.h: For accessing the stack on its top layer and for prototypes of the callback routines to be implemented by the application. hal_api.h: For accessing the HAL and for the prototype of the watchdog expiration callback. All functions prototyped by the API header les may be used to access the stack or the HAL. All function prototypes of callbacks must be implemented within the application. Otherwise the compiler will break and report an error.

2.5.6

Watchdog handling

Deterministic networking can only be guaranteed if the main application does not block for seconds while waiting for events. To disclose this class of errors, the protocol stack implements watchdog handling. In order to ensure correct watchdog triggering, it is required to call apl_run() resp. dll_run() regularly. In case the watchdog expires, the appropriate ISR will jump to the callback function as prototyped by hal_api.h and implemented by the application.

3
3.1

Congurations
Data Link Layer

In [4] the parameters for the phyiscal layer and the data link layer are specied. The API of the stzedn implementation includes functions which are used to send and receive data telegrams via the Wireless M-Bus protocol. It can be used for the M-Bus application layer specied in [3] or a manufacturer specic application layer.

3.2

Application Layer

In [3] an application layer for Wireless and Wired M-Bus is specied. This application layer is used for manufacturer independent data transfer. The API of the stzedn implementation provides functions for sending and receiving data records as specied in [3].

3.3

AT Parser

The serial parser is intended to provide access to the functions of the data link layer and the application layer of Wireless M-Bus specied in chapters 3.1 and 3.2 using a serial interface. The purpose of this interface is to connect a PC or a host controller, and to use the module like a modem, without accessing the modules rmware.

Wireless M-Bus Documentation Version 1.0

ADDITIONAL TOOLS AND FURTHER OPTIONS

page 16

There a two different congurations for this parser. First, an AT-interface based on readable ASCII symbols, and second, a binary interface. The AT-interface is intended for PC connection using a console. It combines multiple commands of the binary interface to easily start communicating over Wireless M-Bus. The binary interface provides access to every single function of data link layer or application layer, and thus optimizes the rmware access. This version is intended to connect a host controller, and it eases the migration from using a module for communicating to the implementation of the protocol stack in the former host controller.

4
4.1

Additional tools and further options

Introduction

The Wireless M-Bus protocol stack from stzedn can be used in different versions. Refer to chapter 2.3 for details. Especially for large networks of some thousand meter devices and data collectors, additional tools are useful to efciently set up and run the network. Those tools are designed and developed by stzednand are described below.

4.2

capt2web Wireless M-Bus Monitoring and Commissioning Tool

Wireless communication benets from commissioning tools during system setup. Once the network is operating, errors or intrusion attempts can be logged. Usually the network monitors require software installation on the monitoring machine. Also, in case of non-standard protocols, additional hardware drivers are necessary to connect the snifng module. The stzedn solution follows a different approach. The snifng device runs an embedded web server, to which any web browser can connect. By default, the connection uses Ethernet but it can also be established via GPRS, modem, and Wi-Fi. Figure 4 shows the hardware device of the stzednfor capturing data.

Figure 4: Hardware for in-eld Wireless M-Bus data monitoring

Web 2.0 services implemented by the web server inside the snifng device regularly refresh the client browser while only transmitting the M-Bus telegrams received. Java scripts are used for telegram ltering, colouring, and evaluation. Figure 5 shows as an example the browser window including the packets timeline. The packets shown

Wireless M-Bus Documentation Version 1.0

ADDITIONAL TOOLS AND FURTHER OPTIONS

page 17

were catched and logged during a session of the demonstration program. Logging to USB Flash Drives and later download logging data makes long-term tests easier. In case of questions or to ask for a quotation for the tool, please contact metering@stzedn.de.

Figure 5: capt2web Network Monitoring Tool

Wireless M-Bus Documentation Version 1.0