Hubbry Logo
logo
Meter-Bus avatar
Meter-Bus
Community hub

Meter-Bus

logo
0 subscribers
Read side by side
Meter-Bus
View on Wikipedia
from Wikipedia

M-Bus or Meter-Bus is a European standard (EN 13757-2 physical and link layer, EN 13757-3 application layer) for the remote reading of water, gas or electricity meters. M-Bus is also usable for other types of consumption meters, such as heating systems or water meters. The M-Bus interface is made for communication on two wires, making it cost-effective. A radio variant of M-Bus Wireless M-Bus is also specified in EN 13757–4.

The M-Bus was developed to fill the need for a system for the networking and remote reading of utility meters, for example to measure the consumption of gas or water in the home. This bus fulfills the special requirements of remotely powered or battery-driven systems, including consumer utility meters. When interrogated, the meters deliver the data they have collected to a common master, such as a hand-held computer, connected at periodic intervals to read all utility meters of a building. An alternative method of collecting data centrally is to transmit meter readings via a modem.

Other applications for the M-Bus such as alarm systems, flexible illumination installations, heating control, etc. are suitable.

Relation to the OSI model

[edit]

Since no bus system was available for the requirements of meter reading, the M-Bus was developed by Horst Ziegler of the University of Paderborn in cooperation with Texas Instruments Deutschland GmbH and Techem GmbH [de]. The concept was based on the ISO-OSI Reference Model, in order to realize an open system which could use almost any desired protocol.

Since the M-Bus is not a network, and therefore does not – among other things – need a transport or session layer, the levels four to six of the OSI model are empty. Therefore, only the physical, the data link, the network and the application layer are provided with functions.

OSI Model
Data unit Layer Standard
Host
layers 		Data 7. Application EN1434-3
6. Presentation Empty
5. Session Empty
Segment/Datagram 4. Transport Empty
Media
layers 		Packet 3. Network Optional
Frame 2. Data link IEC 60870
Bit 1. Physical M-Bus

Physical wire and connectors

[edit]

M-Bus connection is called M-Bus or HAN (Home Area Network) consumer connection. M-Bus uses two-wire telephone cable (JYStY 1x2x0.8 mm or similar, 73 ohm/km, 120 nF/km) maximum length of 350 meters when using nominal transfer speeds 300 and 9600 baud. Lowering the speed up to 1000 meter cable can be used. There is no standardized connector, but RJ11 and RJ12 Modular connectors are used by meter manufacturers.[1]

The master communication uses voltage signaling, where 1 (idle state, mark) is the bus nominal 36 volts, 0 (space) drops the voltage to 24 volts. As bus voltage can vary with length and load, the signal is specified as 1 for bus voltage drop less than 5.5V, 0 for drop higher than 8.2 volts.

Slaves communicate by current consumption, where 1 (idle state, mark) is less than 1.5 milliamperes, 0 (space) raises current to 11–20 mA. The signal is specified as the at least 11 mA current increase.

The slaves are connected via diode bridge and can use either polarity of the wires. To protect the bus against shortcircuited slaves, a 430 ohm is connected in series at each slave (or, two 215 ohm resistors, one for each wire).

A M-bus load unit is 1.5 mA. Most slaves use at most this, some can need two units (3 mA). Masters can provide type-dependent number of load units, and usually visually indicate overload.

[edit]

The data link protocol is described by IEC 870-5, or its updated version, IEC 60870-5.

The data are sent in serial form, at speed between 300 and 9600 bit/s (some variants may operate up to 19200 or 38400 bit/s), using one start bit, one stop bit, and even parity (8e1). The least significant bit is sent first. When sending packets ("telegrams"), there is no pause between stop and subsequent start bit.

Suggested speeds are 300, 2400, 9600, and with newer hardware 38400 bit/s, while 2400 bit/s is most common. Devices with different baudrates can coexist on the same bus. Some devices use Automatic Baud Rate Detection (ABR) or autobauding[clarification needed].

There are four kinds of packets:

  • single character – 0xE5 – acknowledgement
  • short frame, 5 bytes – 0x10, C-field, A-field, checksum, 0x16 – sending simple commands
  • control frame, 9 bytes – 0x68, 0x03, 0x03, 0x68, C-field, A-field, CI-field, checksum, 0x16
    • The control frame is a long frame with no payload.
  • long frame, 9+ bytes – 0x68, length, length, 0x68, C-field, A-field, CI-field, [0..252 payload bytes], checksum, 0x16

C-field is the control/function field. The sequence, from bit 7, is:

  • bit 7: 0
  • bit 6: 1 for master-to-slave, 0 for slave reply
  • bit 5:
    • from master: FCB, frame count bit – indicates request to repeat message when reply was not received
    • from slave: ACD, access demand – 1 when slave wishes to transmit class-1 data, priority data (class-2 data is ordinary non-priority) – the master then should request the class-1 data transfer
  • bit 4:
    • from master: FCV, frame count valid – when 0, slave should ignore FCB
    • from slave: DFC, data flow control – when 1, slave can not accept further data
  • bit 3,2,1,0: F3,F2,F1,F0, function code – e.g. for short frame, 0 is for initialization of slave, xA is for class-1 (priority) data read, xB is for class-2 (normal) read. For long/control frame, x3 is sending data to slave, x8 is data reply from slave.

A-field is the address field. It is a 8-bit number:

  • 0x00 – unset address, assigned at manufacture time, some meters fixed at this
  • 0x01..0xFA – slave addresses
  • 0xFB, 0xFC – reserved
  • 0xFD – "broadcast" for secondary addressing, addressing done on network layer instead of on data link layer
  • 0xFE – test broadcast, all slaves reply (collisions will happen, use for testing with a single slave; slave replies with its own address in A-field), also possible to use when there is only one slave on the bus
  • 0xFF – broadcast, no reply from slaves

CI-field is the control information field. Defined at application layer.[2]

Length field in control/long frame is sent twice. Both bytes have to be equal. Minimum value is 0x03, as C-field, A-field and CI-field are mandatory parts of the payload.

Slaves respond only to correctly formed packets that match their address. Any fault is indicated by lack of response. Absence of response is defined as no response for 330 bit periods (35 ms for 9600 bit/s, 1.1 s for 300 bit/s) plus 50 ms.[3]

Numerical values are usually sent in BCD format.[4]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Meter-Bus

View on Grokipedia
from Grokipedia
Meter-Bus, commonly abbreviated as M-Bus, is a European standard (EN 13757) developed for the remote reading of utility consumption meters, including those for water, gas, electricity, and heat.[1][2] It defines a wired communication protocol that enables efficient data collection from multiple metering devices using a simple two-wire bus system, which simultaneously supplies power and transmits data.[1][2] The standard is divided into key parts, with EN 13757-2 specifying the physical and data link layers, and EN 13757-3 outlining the application layer for meter data handling.[2][3] The protocol employs a master-slave architecture, where a central master device polls connected slave meters for consumption data, supporting up to thousands of devices on a single bus line.[2][1] M-Bus networks can extend up to 1,000 meters without repeaters, and longer distances—up to 8 kilometers—are achievable with repeaters, making it suitable for large-scale installations in residential, commercial, and industrial settings.[2][1] Its design emphasizes cost-effectiveness, robustness against electrical interference, and ease of maintenance, with devices from various manufacturers interoperable via the standardized two-wire connection.[1][2] Originally conceived in the early 1990s to address the need for unified remote metering in Europe, particularly for heat meters, M-Bus has evolved into a foundational technology for automatic meter reading (AMR) systems. It was developed by Professor Dr. Horst Ziegler of the University of Paderborn in cooperation with Texas Instruments Deutschland GmbH.[4][5][2] Beyond traditional utilities, it is applied in building automation for monitoring temperature, pressure, and other sensors, facilitating energy management and billing processes.[1] A wireless variant, defined in EN 13757-4, extends its use to scenarios where cabling is impractical, but the wired M-Bus remains the core for reliable, low-cost deployments.[1][6]

Introduction

Definition and Purpose

Meter-Bus, also known as M-Bus, is a European standard defined by EN 13757 for the remote reading of utility meters, encompassing water, gas, electricity, and heat consumption devices.[7] It establishes a standardized communication framework to facilitate the collection and transmission of metering data in residential, commercial, and industrial settings.[8] The primary purpose of Meter-Bus is to enable cost-effective and low-power data transmission within a master-slave architecture, supporting efficient building automation and utility management systems.[7] This protocol allows a central master device to poll multiple slave meters for consumption data, promoting interoperability and reducing the complexity of integrating diverse metering equipment.[8] In terms of scope, Meter-Bus operates as a primarily wired protocol suited for indoor applications, utilizing a two-wire bus topology that supports up to 250 slave devices per segment.[7] It accommodates baud rates ranging from 300 to 38,400 bits/s, enabling flexible data rates based on network requirements while maintaining compatibility across devices.[7] Key benefits include inexpensive installation facilitated by non-polarized twisted-pair cabling, such as standard telephone wire (e.g., J-Y(St)Y 2x2x0.8 mm), which requires no specific termination or polarity observance.[7] Additionally, basic setups leverage secondary addressing—typically the manufacturer's serial number—eliminating the need for manual address configuration on slaves.[7]

Historical Development

The Meter-Bus (M-Bus) protocol originated in 1990, developed by Professor Dr. Horst Ziegler of the University of Paderborn in collaboration with Texas Instruments Deutschland GmbH and Techem GmbH to address the need for a reliable, low-cost communication system for remote utility meter reading.[9] This initiative responded to the growing demand for unified metering solutions in Europe following the liberalization of energy markets in the 1990s, which introduced competition among utilities and required efficient, standardized data exchange to support billing, monitoring, and grid management.[10][7] Early standardization efforts focused on heat metering applications, leading to the publication of EN 1434-3 in 1997, which defined data exchange and interfaces for heat meters using the M-Bus protocol.[11] By the early 2000s, the protocol had evolved into the broader EN 13757 series, with parts addressing physical and link layers (EN 13757-2, first published around 2005) and application layers (EN 13757-3), establishing M-Bus as a comprehensive European standard for wired communication in metering systems.[12][13] In the 2010s, M-Bus was integrated into the Open Metering System (OMS), an open, vendor-independent framework founded by industry associations like figawa and KNX to enhance interoperability across electricity, gas, heat, and water metering.[14] Key milestones include its adoption as the de facto standard for remote reading in smart metering deployments across Europe and the release of OMS Technical Report 02 (version 2.0.3) in 2024, which specifies compliance requirements for wired M-Bus to ensure data security and compatibility with evolving smart grid infrastructures.[7] As of 2025, M-Bus remains widely deployed in utility metering networks throughout Europe and beyond, with the OMS Group continuing to drive enhancements for greater interoperability, security, and integration with building automation systems.[15]

Technical Specifications

Physical Layer

The physical layer of Meter-Bus, standardized in EN 13757-2:2025, specifies the electrical signaling and transmission medium for asynchronous serial communication over a wired bus, enabling reliable data exchange in utility metering networks.[16] The transmission medium consists of a two-wire non-polarized twisted-pair cable, such as J-Y(St)Y with a 0.8 mm² cross-section per conductor, designed for low capacitance and resistance to support extended installations. Each slave consumes one unit load (1.5 mA) in the idle state, with masters rated to supply multiple unit loads.[17] This configuration allows distances up to 1,000 meters at 2,400 bits/s, limited by total cable capacitance not exceeding 180 nF and resistance considerations for voltage drop.[18] Voltage levels operate with an idle state (logical 1, or Mark) at +21 V to +42 V, typically +36 V, while data transmission (logical 0, or Space) involves a voltage drop of at least 8.2 V, resulting in levels from +6 V to +24 V depending on bus loading.[19] Current consumption per slave is restricted to 1.5 mA in the idle state to ensure compatibility across up to 250 devices.[18] Standardized baud rates encompass 300, 600, 1,200, and 2,400 bits/s as mandatory, with 4,800 and 9,600 bits/s recommended and optional extensions to 19,200 or 38,400 bits/s for shorter networks; transmission follows a UART-like asynchronous serial protocol.[19] Power supply integration allows the bus to deliver DC power to slaves at up to +42 V with total current capacity up to 375 mA (250 unit loads at 1.5 mA each) depending on the master type, powering low-consumption devices without additional sources and maintaining operation during idle periods.[18] Signal encoding employs NRZ-like voltage modulation for master-to-slave transmission and current modulation (11 mA to 20 mA increases) for slave-to-master responses, with collision detection achieved by monitoring bus voltage or current variations.[19]

Data Link Layer

The Meter-Bus (M-Bus) data link layer operates on a master-slave architecture, where the master device initiates all communications by sending request telegrams, and slave devices—such as utility meters—respond only when specifically addressed by their unique identifier. This hierarchical structure ensures orderly access to the shared bus medium without requiring slaves to compete for transmission opportunities. The master maintains control over the bus states through voltage manipulation, transitioning between a mark state (high voltage, approximately 36 V) and a space state (low voltage), while slaves modulate the bus by varying current draw during their responses.[20][19] Medium access control in the M-Bus data link layer is polling-based, with the master sequentially querying slaves to prevent transmission overlaps and eliminate the need for carrier sense multiple access with collision detection (CSMA/CD). The master enforces access by holding the bus in the mark state during idle periods and switching to space only to start a transmission, allowing slaves to detect and synchronize to these signals. Slaves wait for a valid address match before responding, typically within 11 to 330 bit periods plus a 50 ms guard time, ensuring deterministic and collision-free operation in a half-duplex environment.[20][19] Error detection at the data link layer employs an even parity bit for each byte, which verifies the integrity of individual characters during asynchronous serial transmission, combined with a frame-level checksum calculated as the arithmetic sum (modulo 256) of key telegram fields such as control, address, and control information bytes. If errors are detected—through parity failure, checksum mismatch, or invalid start/stop bits—the receiving device discards the frame, prompting the master to retransmit up to two additional times after a timeout period of 330 bit periods plus 50 ms. This mechanism provides reliable data transfer without forward error correction, relying instead on the low error rates of the twisted-pair medium.[9][20] Transmission is byte-oriented, with each byte consisting of a start bit (space level), 8 data bits transmitted least significant bit first, an even parity bit, and one or two stop bits (mark level), enabling baud rates from 300 to 9600 bits per second without inter-byte pauses. Telegrams are structured as variable-length sequences beginning with a start sequence (e.g., single character E5h for acknowledgments or 10h/68h for frames), followed by length indicators, data fields, a checksum byte, and ending with a stop sequence (16h), all framed to support short, control, or long formats as needed for efficient polling.[20][9] Collisions are handled through voltage and current monitoring, as slaves continuously observe the bus voltage during transmission; if the expected voltage drop (due to their own current modulation) does not occur—indicating interference from another slave—the transmitting slave aborts immediately and resets. The master detects potential collisions via overcurrent sensing (e.g., 70–500 mA), signaling a break condition with a prolonged space state (50 ms) or temporarily powering down the bus to resolve faults, thereby maintaining protocol reliability in multi-slave networks.[9][19]

Application Layer

The M-Bus application layer, defined in EN 13757-3:2025, specifies protocols for exchanging metering data between master devices and slaves such as utility meters, focusing on structured commands and responses for reliable data retrieval and configuration.[21] This layer builds on lower layers to enable end-to-end communication tailored to metering applications, ensuring interoperability across diverse meter types.[13] Data encoding in the application layer uses Data Information Fields (DIF), Variable Information Fields (VIF), and Variable Information Field Extensions (VIFE) to represent metering values efficiently. VIF codes specify units such as energy in Wh (VIF 04h) or volume in m³ (VIF 15h), while incorporating multipliers like 10³ for scaling (e.g., MWh).[21] VIFE extends VIF for complex cases, such as adding storage intervals or error flags, with data stored in formats like 32-bit integers, BCD, or variable-length real numbers to optimize transmission.[21] These structures allow compact representation of values, for instance, a 32-bit integer for cumulative kWh consumption multiplied by the VIF factor.[22] Commands in the application layer include requests for data classes: Class 0 for immediate values, Class 1 for stored historical data, and Class 2 for event-based or extended records, initiated by masters via Control Information (CI) codes like 72h for Request Class 1.[21] Responses use corresponding CI codes (e.g., 7Dh for Class 1 response) and include data blocks with DIF/VIF pairs, enabling actions like resets (CI 51h) or parameter settings.[22] Slaves confirm receipt and provide selected data, supporting selective readout to minimize bus load.[9] Telegrams in the application layer support types such as single data (one record per response), variable data (multiple records for comprehensive readout), selection (master-specified variables via data blocks), and user data (custom payloads up to 255 bytes total, with 252 bytes for application data).[22] These are transported within data link layer frames for reliability.[20] Standardization occurs through EN 13757-3:2025 as the companion specification for the application layer, complemented by Open Metering System (OMS) profiles for cross-vendor interoperability in electricity (e.g., active energy in kWh) and heat metering (e.g., thermal energy with flow/return temperatures).[21][13] OMS defines standardized DIF/VIF usage and command subsets, ensuring devices from different manufacturers can exchange data seamlessly across media like electricity and heat.[14] Data security in the application layer provides optional encryption using keys as specified in EN 13757-7:2025, while primary integrity relies on link layer checksums such as CRC or parity for error detection.[23][20] This approach prioritizes robust data validation without mandating application-level cryptography in basic implementations.

Protocol Operation

Relation to OSI Model

Meter-Bus, also known as M-Bus, adopts a simplified protocol architecture that aligns with select layers of the OSI reference model, focusing on efficiency for utility metering applications. Unlike comprehensive protocols such as TCP/IP that implement all seven OSI layers, M-Bus primarily utilizes a three-layer stack—physical, data link, and application—tailored for low-complexity, cost-effective communication in master-slave configurations. This design prioritizes direct data exchange between meters and central reading devices, omitting higher-layer functionalities where unnecessary for its scope. It includes a basic network layer for addressing and management, though without full routing capabilities. Layers 4 through 6 (transport, session, presentation) are empty, with an optional transport layer for security in EN 13757-7.[4][6] The physical layer of M-Bus corresponds to OSI Layer 1 and is specified in EN 13757-2, handling electrical signaling, voltage levels (such as 36 V for logical '1' and 24 V for logical '0' at the master), and cabling requirements for twisted-pair wiring up to 1 km in length. This layer ensures reliable transmission over two-wire bus topology, powering slave devices while transmitting data at baud rates from 300 to 38,400 bits per second.[7] At OSI Layer 2, the data link layer, also defined in EN 13757-2, manages framing, primary and secondary addressing (using 8-bit or 64-bit identifiers), error detection via parity and checksums, and master-slave access control through half-duplex serial communication. It structures telegrams with start/stop bits and ensures collision-free transmission in bus environments supporting up to 250 devices per segment.[7][4] The network layer (OSI Layer 3) provides basic functionality for extended addressing and network management in M-Bus, such as secondary addressing and broadcast modes, rather than full routing; for multi-segment networks, repeaters extend the bus by isolating segments and relaying messages at the physical layer.[18][7] Higher OSI layers are combined within the M-Bus application layer as per EN 13757-3, which handles data formatting using variable information fields (VIFs), and metering-specific exchanges like request-response telegrams. An optional transport layer for security is introduced in EN 13757-7, but basic implementations omit it to maintain simplicity.[7]

Frame Structure and Addressing

The Meter-Bus protocol defines a telegram structure for reliable communication over the wired bus, primarily using the long frame format for data exchange between master and slave devices. This format commences with a start sequence of 0x68, followed by the L-field (a single byte repeated for redundancy), then another 0x68, to signal the beginning of a variable-length message. The L-field specifies the length of the data from the control field through the end of the user data block (up to 252 bytes of user data).[20][24] The structure then includes the control field (C-field), a single byte that dictates the message direction and type, followed by the address field (A-field) as a single byte for device targeting. After the address comes the variable-length data block, which carries protocol-specific information such as command identifiers and payloads, though its content is defined at higher layers. The telegram concludes with a checksum byte (CS-field), computed as the arithmetic sum modulo 256 of all bytes from the C-field through the end of the data block, providing basic error detection, and a stop sequence of 0x16 to mark the end. Shorter telegrams are supported by setting the L-field accordingly, with no explicit padding required beyond the structure itself, allowing efficient transmission of messages from a few bytes to the maximum length.[20][24] The control field employs an 8-bit structure where bit 6 indicates the frame direction (set to 1 for master-initiated requests and 0 for slave responses), bits 5 and 4 manage frame counting via the frame count bit (FCB) and frame count valid bit (FCV) to sequence responses and prevent duplicates, and the lower 4 bits encode the command type—for instance, 0x40 specifies SND_NKE, a reset command to reinitialize a slave device. This bit-level encoding ensures orderly, collision-free exchanges in a master-slave topology.[20][24] Addressing in Meter-Bus operates primarily at the link layer with a 1-byte primary address field, assigning values from 1 to 250 to individual slave devices for direct communication, while the master typically uses 0 and slaves respond with their own primary address. A value of 255 serves as a broadcast address to reach all slaves simultaneously without expecting individual replies, and 254 is designated for network management broadcasts where all devices respond. For initial device discovery or when primary addresses conflict, secondary addressing is invoked by setting the primary address to 253, at which point the full secondary address—comprising a 4-byte device serial number (in binary-coded decimal), a 2-byte manufacturer ID, 1-byte software version, and 1-byte device type—is included in the data block to uniquely identify the target, enabling up to 100 million unique devices per manufacturer. Group addressing for manufacturer-specific subsets is facilitated through secondary addresses filtered by the manufacturer ID in broadcast or discovery modes.[20][24][25]

Hardware and Implementation

Wiring and Connectors

Meter-Bus networks utilize unshielded twisted-pair (UTP) cables with conductor cross-sections ranging from 0.5 to 1.5 mm², such as standard telephone cables like JYSTY 2x0.8 mm, to ensure low capacitance and resistance suitable for reliable signal transmission.[26][27] These cables support maximum segment lengths of up to 350 meters at 9,600 baud or 1 kilometer at 2,400 baud, depending on the number of devices and capacitive limits defined in the EN 13757-2 standard, while the connection is polarity-insensitive to simplify wiring.[27][26] Common connector types for Meter-Bus include screw terminals or Wago spring terminals for secure and easily disconnectable connections, with RJ12 or similar modular plugs used in some adapter setups, though no universal plug standard exists; meter interfaces often employ DIN 43856-compliant 2-pin terminals for the bus lines (A and B).[28][29] Installation follows a preferred daisy-chain (line) topology to minimize signal reflections, supporting up to 250 slave devices, with any stubs or branches limited to less than 5 meters to maintain integrity, and careful attention to voltage drop on longer runs to ensure the minimum 24 V supply at endpoints.[26][28][27] To extend networks beyond 1 kilometer, repeaters are employed to create isolated segments, each providing power management and supporting up to 250 additional unit loads while adhering to EN 13757-2 guidelines for electromagnetic compatibility (EMC) to ensure noise immunity in residential and industrial settings.[26][29][27] These practices allow the bus to deliver both communication and power to devices without dedicated grounding.[27]

Network Topologies and Devices

Meter-Bus, also known as M-Bus, primarily employs a linear bus topology, often implemented in a daisy-chain configuration, where devices are connected sequentially along a two-wire cable to form a single communication line. This setup supports up to 250 slave devices per segment, enabling efficient data polling from a central master without the need for complex wiring.[30][26] For larger installations, Meter-Bus networks can adopt a tree topology by incorporating repeaters, which regenerate signals and extend coverage up to 1,000 meters per segment while maintaining the hierarchical master-slave structure. Repeaters function as virtual masters, allowing multiple levels of extension to support expanded networks without exceeding addressing limits.[17][31] Master devices serve as central controllers in Meter-Bus systems, typically comprising gateways or data concentrators that initiate communication and aggregate data from slaves. Examples include OMS-compliant modules, which ensure interoperability in utility metering setups by adhering to EN 13757 standards for protocol compliance.[7][32] Slave devices encompass a range of endpoints such as meters, sensors, and actuators, which respond to master queries and transmit measurement data. These devices can be powered directly through the bus (up to 1.5 mA per slave) or via external sources, optimizing energy use in low-power environments.[26][18] Repeaters and amplifiers enhance Meter-Bus reliability by boosting signal integrity over long distances or in high-device-count scenarios, with each repeater treated as an addressable entity that isolates segments to prevent voltage drops. They support galvanic separation and can handle up to 250 slaves downstream, enabling scalable tree structures for installations beyond basic linear setups.[33][34] Integration hardware for Meter-Bus includes USB and RS-232 interfaces for direct PC connectivity, as well as modems for remote access over serial links, facilitating data logging and configuration. Power capacity per segment is determined by the master's supply, typically supporting up to 250 unit loads.[35][36]

Applications and Extensions

Utility Metering

Meter-Bus, also known as M-Bus, serves as a primary protocol for remote reading of utility meters in residential and commercial buildings, facilitating automated meter reading (AMR) and minimizing manual site visits for billing and monitoring purposes.[37][8] This wired communication standard enables utilities to collect consumption data from meters for electricity, gas, water, and heat without requiring dedicated telephone lines or complex infrastructure, thereby streamlining operations across multi-utility environments.[38][39] In practice, Meter-Bus supports integrated setups where multiple utility types—such as gas, water, and electricity—are connected via a single bus system, allowing centralized data aggregation.[14] European regulations have driven its adoption, with mandates in countries like Germany and Italy requiring smart metering solutions that incorporate standards like M-Bus to enhance energy efficiency and compliance with EU directives on remote access.[40][41] Key benefits include substantial cost reductions, with installations achieving up to 75% savings on wiring, conduit, and labor compared to traditional pulse-based systems, as no additional communication lines are needed.[42] It also enables detailed data logging for consumption pattern analysis, helping utilities optimize resource allocation, and supports fault detection through embedded status reporting, which alerts operators to issues like leaks or malfunctions in real time.[43][44] Notable deployments highlight its scalability; for instance, large-scale projects in Germany and Italy have integrated Meter-Bus into national smart metering rollouts, serving millions of households and enabling seamless multi-utility monitoring.[40] By 2025, Meter-Bus-based systems, often certified under the Open Metering System (OMS) framework, have been installed in extensive European networks, ensuring vendor interoperability and supporting millions of smart meter endpoints where M-Bus serves as a core protocol for utilities like water and gas.[38][39] In Poland, a combined electricity, gas, and water metering initiative using M-Bus and OMS has reduced operational costs while improving data accuracy across urban installations.[45] Despite its advantages, Meter-Bus faces challenges from its limited data rate, which suits low-frequency readings but requires periodic polling strategies to manage high-volume logging without overwhelming the network.[46] This approach, combined with OMS certification, mitigates interoperability issues and maintains reliability in diverse utility deployments.[15]

Wireless Variants and Security

Wireless M-Bus represents an extension of the wired Meter-Bus protocol, standardized under EN 13757-4, enabling radio-based communication for utility meters and data collectors without physical cabling, particularly suited for outdoor and remote metering applications.[47] This wireless variant operates primarily in license-free ISM bands such as 868 MHz in Europe, facilitating deployment in scenarios where wiring is impractical, such as urban water or gas distribution networks.[48] The standard defines several communication modes optimized for different ranges, data rates, and power requirements. Mode S, commonly used for stationary, uni-directional communication, achieves 32 kbit/s at 868 MHz, supporting long-range transmissions up to several kilometers in open air.[47] Mode T, bidirectional and low-power, operates at 100 kbit/s for extended battery life in compact devices, ideal for setups up to 1 kilometer.[49] Mode C provides up to 100 kbit/s bidirectional communication at 868 MHz, balancing range (up to 500 meters) and reliability for remote reading in less dense environments.[47] These modes ensure compatibility with battery-powered slave devices, such as meters, while maintaining interoperability through Open Metering System (OMS) profiles.[13] Adoption of Wireless M-Bus has grown significantly in smart city initiatives across Europe, where it supports scalable data collection from thousands of meters in urban settings.[50] Gateways serve as intermediaries, aggregating meter data and bridging it to IP-based networks for centralized management and analysis.[48] OMS profiles, standardized for multi-utility applications, enable battery-powered slaves to operate efficiently, with widespread use in water and energy metering projects that emphasize low-cost, long-life deployments.[13] Security in Wireless M-Bus has been enhanced through updates in the 2010s, incorporating AES-128 encryption to protect data confidentiality and integrity during transmission.[51] Specific modes, such as Mode 7, combine AES-128 in CBC for encryption with CMAC for authentication, using shared keys often embedded in secondary addressing frames to verify device legitimacy.[23] Additional mitigations include replay protection via sequence counters and timestamping, reducing risks from interception or unauthorized access in open ISM bands.[50] These features align with OMS-compliant schemes, ensuring robust protection for sensitive metering data.[50] Looking ahead, Wireless M-Bus is integrating with broader IoT ecosystems, including hybrids with LoRaWAN for extended range in low-power wide-area networks, as outlined in 2025 OMS specifications and LoRa Alliance initiatives.[52] Emerging developments also explore 5G compatibility for high-reliability remote access, enhancing real-time data handling in smart grids and home automation.[53] These advancements aim to address scalability in dense IoT environments while maintaining backward compatibility.[52] Despite these benefits, Wireless M-Bus faces limitations compared to its wired counterpart, including reduced reliability due to interference in shared ISM spectrum, which can degrade signal quality in noisy urban areas.[54] Additionally, while designed for low power, battery-operated devices consume more energy overall than wired setups powered by the bus, necessitating careful duty cycle management to achieve multi-year lifespans.[55] These constraints highlight the trade-offs in wireless deployments for remote metering.[55]

References

  1. M-Bus - European Standard (EN 13757) - Holosys
  2. Understanding the M-Bus Protocol , Physical Layer of M-Bus , Link Layer and Application Layer of M-Bus , Implementing M-Bus in Industrial Applications , Configuring the Master and Slave Devices , Integrating M-Bus Data into the Data Management System , Benefits of Using M-Bus in Industrial Applications , Conclusion
  3. M-Bus - Energy Machines Cloud
  4. https://consteel-electronics.com/articles/how-to-understand-mbus
  5. Wireless M-Bus Technology Overview - Radiocrafts
  6. [PDF] Open Metering System Technical Report 02 Wired M-Bus Version ...
  7. M-Bus: Home
  8. [PDF] Downloads - M-Bus
  9. [PDF] A history of electricity liberalisation - Edinburgh Research Explorer
  10. https://standards.iteh.ai/catalog/standards/cen/cb1b364c-0fee-4cf5-8153-1fcbec0c07f7/en-1434-3-2015
  11. https://standards.iteh.ai/catalog/standards/cen/bce9d221-d526-4442-a8fa-eb2e6917c125/en-13757-2-2018a1-2023
  12. [PDF] Open Metering System Specification - oms-group.org
  13. Home - Open Metering System Group - oms-group.org
  14. Specification - Open Metering System Group - oms-group.org
  15. https://standards.iteh.ai/catalog/standards/sist/bc24fe34-fd41-43aa-8641-1e8193b2e090/sist-en-13757-2-2018a1-2024
  16. [PDF] M-Bus connection for energy and consumption meters - download
  17. 4 – Physical Layer - M-Bus
  18. [PDF] SIST EN 13757-2:2018+A1:2024 | iTeh Standards
  19. 5 – Data Link Layer - M-Bus
  20. [PDF] SIST-EN-13757-3-2018.pdf - iTeh Standards
  21. 6 – Application Layer - M-Bus
  22. [PDF] AN043: Wireless M-Bus Security - Radiocrafts
  23. Wired M-Bus Specification
  24. None
  25. jMBus User Guide – M-Bus - OpenMUC
  26. [PDF] M-Bus Network Wiring Guidelines - BMETERS metering solutions
  27. [PDF] Open Metering System Technical Report 02 Wired M-Bus Version ...
  28. Installation of M-Bus communication bus, part 1
  29. [PDF] Wired MBus Network & Data Logger Installation Guide | Sycous
  30. M-Bus Connection - iSMA CONTROLLI
  31. [PDF] M-Bus Master MultiPort 250L
  32. https://www.icpdas-usa.com/m_bus_gateway.html
  33. [PDF] M-Bus interface repeater RepeaterMBusXL - JC Elektronika s.r.o.
  34. [PDF] M-bus level converter/repeater 250 - RS Online
  35. LRS232-802 Interface - Loytec
  36. M-Bus adapter & Protocol Converter | AD-01 ᐅ Westermo
  37. [PDF] M-Bus Compatible Meter Reading and Billing Process - theijes
  38. OMS certification - Open Metering System Group
  39. IoT in Utilities: Smart Meter Connectivity for Water and Energy - Eseye
  40. 2027 Is Closer Than You Think: Preparing for Europe's Remote ...
  41. The Role of Smart Meters in Enabling Real-Time Energy Services ...
  42. M-Bus Versus Pulse For Water And Thermal Metering - QMC
  43. M-bus: A Robust Communication Protocol - Smowcode Blogs
  44. What is MBus? And How is it used in Metering Systems?
  45. The EU's Smart Metering Imperative
  46. Unleashing the benefits of smart grids by overcoming the challenges ...
  47. [PDF] Wireless M-Bus 101: Demystifying modes and regional application ...
  48. [PDF] An Introduction to Wireless M-Bus - Silicon Labs
  49. What is wireless MBus? - Lupus Electronics
  50. Wireless M-Bus for Smart Metering: Enabling Efficient Utility Data ...
  51. Exploring M-Bus, security and efficiency in telemetry communications
  52. OMS Over LoRaWAN – Bringing Smart Metering to the Next Level
  53. Wireless M-BUS: An Attractive M2M Technology for 5G-Grade Home ...
  54. Investigations of the Wireless M-Bus System Resilience under ...
  55. [PDF] Wireless M-Bus - Carlo Gavazzi Automation
User Avatar
No comments yet.