Every value a DNP3 outstation reports - a pump run status, a tank level, a flow rate - lives at a specific address, and in DNP3 that address is called a point index. Unlike Modbus, where one long list of register numbers holds everything, DNP3 numbers its points separately within each data type, so index 5 is a different thing depending on whether you mean a binary input or an analog input. This guide explains what a point index is, why the numbering restarts per object type, and how a point map connects an outstation's index list to named tags in a cloud SCADA master.
DNP3 Point Index in one line: A DNP3 point index is the zero-based number that identifies an individual data point within a specific DNP3 object type at an outstation - binary input 0, analog input 5, binary output 3, and so on. Each object type has its own independent index range starting at zero, so the same index number can refer to completely different values in different object groups. A DNP3 master reads or writes a value by naming both the object type and the index, and a point map documents what real-world signal each index represents.
DNP3 does not have a single flat address space. Instead, it divides data into object groups by type - binary inputs, binary outputs, analog inputs, analog outputs, counters, and a few others - and each group is indexed independently starting at zero. So an outstation might have binary inputs 0 through 40 for discrete statuses like pump-running and valve-open, and separately analog inputs 0 through 25 for measured values like pressure and level. Analog input 0 and binary input 0 are entirely unrelated points that happen to share an index number, because the index only has meaning together with its object type.
This structure follows directly from how the protocol is built. A DNP3 point is fully identified by three pieces of information: the group (which broad object category, such as analog input), the variation (how that value is encoded on the wire - for example a 16-bit integer, a 32-bit integer, or a floating-point value with a quality flag and timestamp), and the index (which specific point within the group). When a master asks for analog input group data, the outstation returns each requested point tagged with its index, so the master can line the returned values up against its own list. The index is therefore the outstation's internal address for a signal, assigned when the outstation is configured.
Because the numbering is per type and zero-based, reading a DNP3 device without documentation is nearly impossible. Index 12 tells you nothing on its own - you need to know it is an analog input, and you need the outstation's configuration to know that analog input 12 is, say, the separator's operating pressure in kPa. The indexes are assigned by whoever configures the RTU or PLC acting as the outstation, and they are stable for that device, but they carry no built-in description. That is why the point list, described below, is the single most important artifact when integrating a DNP3 outstation.
The contrast with Modbus is the clearest way to understand the DNP3 point index. Modbus organizes data into four large, flat tables - coils, discrete inputs, holding registers, and input registers - and within each table you address data by a single register number, with no notion of an object type carrying quality or timestamp. A holding register is just sixteen bits at an address; if you want a 32-bit float or a device status, you and the master have to agree on a convention layered on top of raw registers, because Modbus itself does not describe what a register means.
DNP3's point index is richer because the object type is part of the address. When a master reads analog input index 5, it knows the value is an analog measurement, and depending on the variation it may also receive an online/offline quality flag and a timestamp for when the outstation captured the reading. Modbus has no such standard companion data; a register value arrives with no indication of whether the field device even considers it valid. This is one reason DNP3 is common on utility and remote-telemetry links where knowing a value's quality and time matters as much as the value itself.
In practical terms, a Modbus map is a spreadsheet of register numbers and a data-type convention you impose, while a DNP3 map is a set of per-type index lists. Both are ultimately lookup tables an integrator must build and maintain, but the DNP3 version splits into columns for group, variation, and index rather than one register column. Neither protocol names its points for you - the burden of mapping numbers to meaning falls on the engineer either way - but DNP3's structure at least tells you a point's category and often its quality directly from the protocol response.
A point map, sometimes called a point list, is the document that turns an outstation's anonymous indexes into meaningful tags. For each point it records the object group, the variation, the index, engineering units, scaling, and a human-readable description - for instance, that analog input 8 is the tank-battery level in metres with no scaling applied, or that binary output 2 is the chemical-injection pump start command. This map is the contract between the field device and everything upstream; get one index wrong and the master will happily display the wrong signal under the right label.
In a cloud SCADA such as Merobix, the master lives in a browser-delivered platform rather than a local workstation, but the mapping problem is identical: the platform must know that analog input 8 from outstation X corresponds to the tag named Tank-3 Level. Merobix reads DNP3 outstations at remote pads and facilities, and its configuration ties each object-group-and-index to a named, engineering-unit tag so operators see Separator Pressure rather than a raw index number. Once that map is in place, the same tag flows into trends, alarms, and the field overview like any other data source.
This mapping step is exactly where careful DNP3 integration pays off. Because indexes are assigned when the outstation is built and are not self-describing, the cloud master depends entirely on an accurate point map - and on that map staying in sync when the field is expanded. Adding a new analog input at the RTU means adding its index to the map so the platform picks it up; deleting or renumbering points at the outstation without updating the master is a classic source of silently mislabeled data. Treating the point map as controlled documentation, versioned alongside the outstation configuration, is what keeps a DNP3-fed cloud SCADA trustworthy as sites change.
Because DNP3 addresses data by object group first and index second, each group is a separate, independently numbered list. Binary inputs are numbered from zero, analog inputs are numbered from zero, and so on, so the same index number in two different groups points to two unrelated signals. The index only identifies a point when you also state its object type.
A Modbus register number is a single flat address in one of four large tables and carries no built-in meaning or quality information. A DNP3 point index is paired with an object group and variation, so the address itself tells you the point's category and often includes a quality flag and timestamp. Both still require an engineer to document what each address represents.
The data will still transfer, but it will be labeled wrong. If a master expects analog input 5 to be pressure and the outstation has renumbered that index to level, the platform will display level values under a pressure tag with no error. Keeping the point map versioned and synchronized with the outstation configuration is the only reliable defense against this kind of silent mislabeling.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.