Exhibit_7_-_Sunspec_Alliance_Information_Models.pdf

Common Models Specification 1 www.sunspec.org

Document #: A12031-1.6 Status: Approved Version 1.6 Approval date: 06-01-2013

Common Models SunSpec Alliance Specifications

Contributors:

John Blair, John Nunneley, Karl Lambert, Pat Adamosky, Ronnie Petterson, Lynn Linse, Bill Randle, Bob Fox, Aaron Parker, Tom Tansy

Abstract This document describes the common elements of the SunSpec information modeling system and is an approved SunSpec Alliance interoperability specification.

Common Models Specification 2 www.sunspec.org

Copyright © SunSpec Alliance 2009-2014. All Rights Reserved.

All other copyrights and trademarks are the property of their respective owners.

License Agreement and Copyright Notice This document and the information contained herein is provided on an "AS IS" basis and the SunSpec Alliance DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY

IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR

PURPOSE.

This document may be used, copied, and furnished to others, without restrictions of any kind, provided that this document itself may not be modified in anyway, except as needed by the SunSpec Technical Committee and as governed by the SunSpec IPR Policy. The complete policy of the SunSpec Alliance can be found at www.sunspec.org.

Prepared by the SunSpec Alliance

4030 Moorpark Avenue, Suite 109

San Jose, CA 95117

Website: www.sunspec.org

Email: info@sunspec.org

Common Models Specification 3 www.sunspec.org

Revision History Revision Date Reason

1.3 06-01-2013

• Added change history

• Allow device aggregation via multiple common blocks

• Manufacturer ID should be registered with

SunSpec

• Added M/O/C column to xls map

• Require Manufacturer, Model, and Serial

Number to be supplied

1.4 Add Copyright

1.5

• Updated Logo

• Corrected Assigned ID range for String

Combiner and Module

• Added Assigned ID ranges for Inverter model, version 1.2, Module model, version 1.1, Inverter Controls and Network Interface

• Added concept of a scale factor as a basic SunSpec type

• Added concept of SunSpec Device type to Common Block

• Changed over to new names for points

• Added definition for acc64, ipaddr, ipv6addr types

• Scale factor clarification wrt unimplemented

• Align the document with the new short names

1.6 09-24-2014 Change to new SunSpec document format

Common Models Specification 4 www.sunspec.org

About the SunSpec Alliance The SunSpec Alliance is a trade alliance of developers, manufacturers, operators and service providers, together pursuing open information standards for the distributed energy industry.

SunSpec standards address most operational aspects of PV, storage and other distributed energy power plants on the smart grid—including residential, commercial, and utility-scale systems— thus reducing cost, promoting innovation, and accelerating industry growth.

Over 70 organizations are members of the SunSpec Alliance, including global leaders from Asia, Europe, and North America. Membership is open to corporations, non-profits, and individuals.

For more information about the SunSpec Alliance, or to download SunSpec specifications at no charge, please visit www.sunspec.org.

About the SunSpec Specification Process SunSpec Alliance specifications are initiated by SunSpec members desiring to establish an industry standard for mutual benefit. Any SunSpec member can propose a technical work item.

Given sufficient interest and time to participate, and barring any significant objections, a workgroup is formed and its charter is approved by the board of directors. The workgroup meets regularly to advance the agenda of the team.

The output of the workgroup is generally in the form of an Interoperability Specification. These documents are considered to be normative, meaning that there is a matter of conformance required to support interoperability. The revision and associated process of managing these documents is tightly controlled. Other documents are informative, or make some recommendation with regard to best practices, but are not a matter of conformance. Informative documents can be revised more freely and frequently to improve the quality and quantity of information provided.

SunSpec Interoperability Specifications follow this lifecycle pattern of DRAFT, TEST, APPROVED and SUPERSEDED.

For more information or to download a SunSpec Alliance specification, go to http://www.sunspec.org/specifications.

Common Models Specification 5 www.sunspec.org

Table of Contents Table of Figures Nomenclature

1. INTRODUCTION

2. SUNSPEC DEVICE TYPES

3. SUNSPEC COMMON MODELS AND CONVENTIONS

4. COMMON DEVICE MODEL

4.1 Common Block

4.2 Device Specific Block

4.3 End of SunSpec Device Marker

5. STANDARD DATA FORMATS

5.1 16 bit Integer Values

5.2 32 bit Integer Values

5.3 64 bit Integer Values

5.4 128 Bit Integer Values

5.5 String Values

Floating Point Values

5.6 Scale Factors

6. DEFINED UNITS

7. ASSIGNED VALUES

7.1 SunSpec ID: Assigned Model IDs

7.2 C_Status: Assigned Status Codes

8. MODBUS REGISTER MAPPINGS

SunSpec Base and Alternate Base Register Addresses (decimal values)

9. COMMON MODBUS MODEL MAPPING

Common Models Specification 6 www.sunspec.org

Table of Figures Figure 1: Example SunSPec Device with no two-device specific blocks Figure 2: 16 bit integer values Figure 3: 32 bit integer values Figure 4: 64 bit integer values Figure 5: Example string values data format Figure 6: Floating point values Figure 7: Common Modbus Model Mapping

Common Models Specification 7 www.sunspec.org

Nomenclature Abbreviation Meaning DA Protocol specific value to address device instance

ID Device Identity

L Length of device model block

Md Manufacturer-specific value identifying device model

Mn Value identifying device manufacturer

Opt Manufacturer specific value identifying any model options for the device

Pad Sunspec pad16 register

RTU Remote Telemetry Unit

SN Manufacturer-specific value identifying device within the manufacturer name space

TCP Transmission Control Protocol

Vr Manufacturer-specific value identifying firmware version of the device

XML Extensible Markup Language

Common Models Specification 8 www.sunspec.org

1. INTRODUCTION

The SunSpec Alliance Interoperability Specifications describe the information models and Modbus register mappings for devices used in Renewable Energy systems. A physical device, such as an inverter, is represented by a collection of one or more of these logical models. This document describes the Common Models and model design conventions. All SunSpec devices must contain the device information common model that describes this particular device as the first logical block of the device.

The data models can be easily moved by XML and other technology, so these specifications are not tied to the 30-year old Modbus protocol; Modbus is the initial implementation specified because Modbus is well understood and supported within renewable energy systems.

2. SUNSPEC DEVICE TYPES

Each type of device is defined in a separate document that details the fields and values specific to that type. Current SunSpec Device Types defined are

1. Inverter

2. Meter

3. Weather Station

4. String Combiner

5. PV Module

6. Tracker

7. Charge Controller

8. Storage

99. Other Additional device models will be taken up and defined as directed by the SunSpec Alliance membership.

3. SUNSPEC COMMON MODELS AND CONVENTIONS

This document focuses on the elements of the specification that are common to all device types.

• Common data model

• Standard data formats

• Modbus register mappings

• Device Specification Format

• Extensibility

• Device Aggregation model

• Network configuration models

• Optionality

Common Models Specification 9 www.sunspec.org

4. COMMON DEVICE MODEL

All SunSpec devices support a consecutive collection of well-defined blocks, each prefaced with a well known Device Identity and length field. This allows a remote client to browse the contents skipping blocks with unrecognized Device Identity (ID) values. The Common Model specifically allows for extensibility in the following ways:

1. Definition of new Device Specific Blocks. New devices are defined and assigned a new device model id.

2. Revisions of Device Specific Blocks. Revisions to device models are defined and assigned a new device model id. Simple models may be appended to without affecting backwards compatibility and do not require a new model id. Readers shall rely on the length of the model to determine this.

3. Vendor specific extensions. Models may include fields that have vendor specific values.

An example of this is the status and event code fields. Vendors may also define a Vendor Extension Block that includes fields and values specific to the vendor. These are assigned a device type id. This block may be then concatenated to the associated Device Specific Block.

4. Composite device types. Device Specific Blocks may be concatenated together to form a composite device. An example of this is a Weather Station represented by a collection of environmental models.

5. Device aggregations. A map may contain multiple Common Blocks. Each Common Block marks the start of a new device. This is useful when a map represents an aggregation of devices. (See the Module/Panel specification for an example of this usage.)

All SunSpec devices must include at least three blocks:

• The first block is the Common Block, which supplies vendor and model information for the device.

• The second (and subsequent) blocks will be device specific – for example a meter block, or a meter block followed by a GPS Location block.

• The final End Block formally marks the end of the Device Specific Blocks.

4x40001 Common Block

4x40070 Device Specific Block

4x40122 Device Specific Block

4x40184 End Block Figure 1: Example SunSPec Device with no two-device specific blocks

Data Element Optionality Data element support may be designated as Mandatory, or Optional. Mandatory means the attribute is required to be supported. Optional means the element is not required.

Implementations shall return the “Not Supported” value if the element is not used in this case.

4.1 Common Block

Common Models Specification 10 www.sunspec.org

The following data elements shall be provided to uniquely identify a SunSpec device.

• SunSpec_ID – A well-known value that confirms to the client that this device has implemented a collection of SunSpec Alliance Device blocks.

• ID – A well-known value that uniquely identifies the specific type of SunSpec device model this block represents. The IDs are assigned by SunSpec. For the Common Block, this value is “1”.

• L – A value that is the length of the device model block in Modbus 16-bit registers. This value does NOT include the ID or L. I.e. it is the number of registers that follow the length. For the Common Block, this value is 66 but may be 65. All SunSpec device blocks should be of even length. Common Blocks of length 66 shall contain the SunSpec pad16 value as the final register.

• Mn – A unique value that identifies the Manufacturer of this device. Manufacturers are encouraged to register their ID with SunSpec to guarantee uniqueness. SunSpec maintains a database of certified products by Manufacturer. The Mn should be concise and constrained to simple alphanumeric text void of spacing.

• Md – A manufacturer specific value that identifies the model of this device. SunSpec maintains a database of certified products by Model. The Md should be concise and constrained to simple alphanumeric text void of spacing.

• Opt - A manufacturer specific value that identifies any model options for this device.

• Vr - A manufacturer specific value that identifies the firmware version of this device.

• SN - A manufacturer specific value that uniquely identifies this device within the manufacturer name space.

• DA - Protocol specific value to address this device instance. For Modbus devices, this is the Modbus device ID.

• Pad – SunSpec pad16 register. Must be included for Common Blocks of length 66. Not included if length is 65.

Note: SunSpec requires that the result of concatenating the three strings Mn, Md, and SN returns a globally unique string for all of a manufacture’s products. If the optional Md value is not implemented, then concatenating the two strings Mn and SN must be a globally unique string. This string may be used by logging and uploading functions, for example.

4.2 Device Specific Block

The SunSpec Common Model is then followed by one or more device specific blocks of data values. The Device Specific Block begins like the Common Model Block.

• ID – A well-known value that uniquely identifies the specific type of SunSpec device model this is.

• L – A value that is the length of the device model block in registers. The length should be even and may contain a rounding pad register. The length does not include the ID or L register. It is the number of registers that follow.

• Model data fields would follow as required. If the ID is not, the L value is used to skip over the model data and move to the next block.

4.3 End of SunSpec Device Marker

Common Models Specification 11 www.sunspec.org

The overall SunSpec Device Block is punctuated by a termination ID ((0xFFFF)) followed by a length value of zero.

5. STANDARD DATA FORMATS

The Modbus specification is not explicit on how to encode numbers other than 16 bit integers.

Differences do exist between one manufacturer’s implementation and another’s. Not all implementations of a specific device will support all of the values defined for that device.

Unsupported values are indicated by supplying the “NOT_IMPLEMENTED” type specific value in response. This specification restricts values to the following standard data formats.

5.1 16 bit Integer Values Values are stored in big-endian order per the Modbus specification and consist of a single register. All integer values are documented as signed or unsigned. All signed values are represented using two’s-compliment.

Modbus Register 1 Byte 0 1 Bits 15 14 13 12 10 11 9 8 7 6 5 4 3 2 1 0

Figure 2: 16 bit integer values int16 Range: -32767 … 32767 Not Implemented: 0x8000 uint16 Range: 0 … 65534 Not Implemented: 0xFFFF acc16 Range: 0 ... 65535 Not Accumulated: 0x0000 pad16 Range: 0x8000 Always returns 0x8000

NOTE: it is up to the master to detect rollover of accumulated values.

5.2 32 bit Integer Values 32 bit integers are stored using two registers in big-endian order

Modbus Register

1 2

Byte 0 1 2 3 Bits 31 … 24 23 … 16 15 … 8 7 … 0

Figure 3: 32 bit integer values int32 Range: -2147483647 … 2147483647 Not Implemented: 0x80000000 uint32 Range: 0 … 4294967294 Not Implemented: 0xFFFFFFFF acc32 Range: 0 ... 4294967295 Not Accumulated: 0x00000000 ipaddr 32 bit IPv4 address Not Configured: 0x00000000

NOTE: it is up to the master to detect rollover of accumulated values.

Common Models Specification 12 www.sunspec.org

5.3 64 bit Integer Values 64 bit integers are stored using four registers in big-endian order.

Modbus Register

1 2

Byte 0 1 2 3 Bits 63 … 56 55 … 48 47 … 40 39 … 32

Modbus Register

3 4

Byte 4 5 6 7 Bits 31 … 24 23 … 16 15 … 8 7 … 0

Figure 4: 64 bit integer values int64 Range: -9223372036854775807 … 9223372036854775807

Not Implemented: 0x8000000000000000 acc64 Range: 0 ... 9223372036854775807 Not Accumulated: 0

NOTE: Only positive values in the int64 range are allowed. Values outside of this range shall be considered invalid.

NOTE: This value shall rollover after the highest positive value in the int64 range (0x7fffffffffffffff). It is up to the reader to detect rollover of accumulated values.

5.4 128 Bit Integer Values 128 bit integers are stored using eight registers in big-endian order.

ipv6addr 128 bit IPv6 address Not Configured: 0

5.5 String Values

Store variable length string values in a fixed size register range using a NULL (0 value) to terminate or pad the string. For example, up to 16 characters can be stored in 8 contiguous registers as follows

Modbus Register 1 2 3 4 5 6 7 8 Byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Character E X A M P L E spc S T R I N G ! NULL

Figure 5: Example string values data format

NOT_IMPLEMENTED value: all registers filled with NULL or 0x0000

Floating Point Values Floating point values are 32 bits and encoded according to the IEEE 754 floating point standard.

Modbus Register

Byte 0 1

Common Models Specification 13 www.sunspec.org

Bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16

IEEE

sign Exponent Fraction

Modbus Register

Byte 2 3 Bits 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

IEEE

Fraction least

Figure 6: Floating point values float32 Range: see IEEE 754 Not Implemented: 0x7FC00000 (NaN)

5.6 Scale Factors

As an alternative to floating point format, values are represented by integer values with a signed scale factor applied. The scale factor explicitly shifts the decimal point to the left (negative value) or the right (positive value). Scale factors may be fixed and specified in the documentation of a value, or may have a variable scale factor associated with it. E.g. A value “Value” may have an associated value “Value_SF” of type “sunssf” that is a 16 bit two’s compliment integer.

sunssf signed range: -10 … 10 Not Implemented: 0x8000 or 0x0000 NOTE: Any value outside of the sunssf range shall be considered to be “Not Implemented”.

6. DEFINED UNITS

No units are defined as part of the Common Model. Units are defined as needed by specific device models. Where units are shared across device models, care will be taken to ensure a common definition of those units.

7. ASSIGNED VALUES

Values that are well known and part of the Common model are defined here.

Note: Current / latest list of assigned values can be found at http://sunspec.org/AssignedIDs SunSpec ID: 0x53756e53 (“SunS”)

7.1 SunSpec ID: Assigned Model IDs

The following device model identifiers have been assigned

0XX Common Models 001 - Common Block

Common Models Specification 14 www.sunspec.org

002 – Aggregator Block 01X Configuration Models

010 – Interface Configuration Model 011 – Ethernet Link Configuration

012 – IPv4 Protocol Configuration 013 – IPv6 Protocol Configuration

014 – Proxy Server Configuration 015 – Interface Packet Counters

016 – Simplified Network Configuration 1XX Inverter Models

101 - Single Phase Inverter Model (Integer+SF) 102 - Split Phase Inverter Model (Integer+SF)

103 - 3 Phase Inverter Model (Integer+SF) 111 - Single Phase Inverter Model (Floats)

112 - Split Phase Inverter Model (Floats) 113 - 3 Phase Inverter Model (Floats)

120 – Inverter Controls Nameplate Ratings 121 – Inverter Controls Basic Settings

122 – Inverter Controls Measurements and Status 123 – Inverter Controls Immediate Controls

124 – Inverter Controls Basic Storage Control 125 – Inverter Controls Pricing Signal

126 – Inverter Controls Static Volt-VAR Arrays 127 – Inverter Controls Frequency Watt Control

128 – Inverter Controls Dynamic Reactive Current 129 – Inverter Controls LVRT Arrays

130 – Inverter Controls HVRT Arrays 131 – Inverter Controls Watt-Power Factor Arrays

132 – Inverter Controls Voltage-Watt Arrays 133 – Inverter Controls Basic Scheduling

2XX Meter Models 201 - Single Phase Meter Model

202 - Split Phase Meter Model

Common Models Specification 15 www.sunspec.org

203 - Wye-Connect Meter Model 204 - Delta-Connect Meter Model

3XX Environmental Models 301 - Base Meteorological Model (DEPRECATED)

302 - Irradiance Model 303 – Back of Module Temperature Model

304 - Inclinometer Model 305 - Location Model

306 - Reference Point Model 307 – Base Meteorological Model (Corrected)

308 – Mini Meteorological Model 4XX String Combiner Models

401 – Basic String Combiner (superseded) 402 – Advanced String Combiner (superseded)

403 – Basic String Combiner 1.1 404 – Advanced String Combiner 1.1

5XX PV Module (Panel) Models 501 – Panel Model (Float)

502 – Panel Model (Integer) 64XXX Vendor Extension Blocks

See http://SunSpec.org/AssignedIDs for the latest 65XXX SunSpec Reserved

65535 - End of SunSpec Map (0xFFFF)

7.2 C_Status: Assigned Status Codes

Devices that support a status code value in the Device Specific Block shall support the following status values.

C_STATUS_NORMAL 0x00000000 : Operating Normally C_STATUS_ERROR 0xFFFFFFFE : Generic Failure

C_STATUS_UNK 0xFFFFFFFF : Status Unknown Device specific status codes shall be defined in corresponding device model.

Common Models Specification 16 www.sunspec.org

8. MODBUS REGISTER MAPPINGS

All SunSpec device register maps will have a well-known base address with an alternate base address that may be used if the base address is unavailable for a particular manufacturer’s device model. The first register in the map shall be the well-known 32-bit identifier SunSpec_ID. This allows for discovery of SunSpec compatible devices. If the base register does not return this value, the alternate base register shall be checked. If this test fails, the device is not SunSpec compatible. The next value indicates the SunSpec device model type. The first device model block shall always be the SunSpec Common Model. The third value is the length of the device model block, followed by the device model values. Additional device model types are concatenated with their corresponding type, length, and values.

SunSpec Base and Alternate Base Register Addresses (decimal values) Preferred Base Register: 40001

Alternate Base Register: 50001 Alternate Base Register: 00001

Base registers are actual register offsets that start at 1 – not a function code and not to be confused with the Modicon convention, which would represent these as 4x40001 and 4x50001.

To read register 40001, use the hexadecimal offset of 0x9C40 (40,000) on the wire.

If you read beyond the end of the block, an exception may or may not be thrown according to the implementation. If no exception is thrown, then data that comes after the End Block is invalid and should not be used. It is recommended that masters read the common block to determine the contents of the map.

Fixed device block sizes must be the size as defined. It is nonconforming to truncate a fixed size device block.

REMINDER: This specification only addresses the format of the data. The data can be moved via Modbus/TCP or RTU – or any other media that can move Modbus data. Implementations are responsible for returning measured values as designed. For example, power and voltage readings may not be in sync depending on the product design.

Common Models Specification 17 www.sunspec.org

9. COMMON MODBUS MODEL MAPPING

Modbus maps are defined using this common table format.

Start End # R/W Name Type Units Scale Factor Contents Description M/O

1 2 2 R SunSpec_ID uint32 N/A N/A 0x53756e53

Well-known value.

Uniquely identifies this as a SunSpec Modbus Map

M

(SunS)

3 3 1 R ID uint16 N/A N/A 0x0001

Well-known value.

Uniquely identifies this as a SunSpec Common Model block

M

4 4 1 R L uint16 registe rs N/A 65,66 Length of common model block M

5 20 1 6 R Mn String(

32) N/A N/A N/A Well-known value M

21 36 1 6 R Md String(

32) N/A N/A N/A Manuf specific value O

37 44 8 R Opt String(

16) N/A N/A N/A Manuf specific value O

45 52 8 R Vr String(

16) N/A) N/A N/A Manuf specific value O

53 68 1 6 R SN String(

32) N/A N/A N/A Manuf specific value M

69 69 1 R/W DA uint16 N/A N/A N/A Device Address O

70 70 1 R Pad pad16 N/A N/A N/A Pad register to make the model even

O

71 71 1 R ID uint16 N/A N/A Device Id Start of next Device M

72 72 1 R L unit16 N/A N/A Device Length

Device Model Block Size M

73 … Length Registers of Device Model Specific Data

Common Models Specification 18 www.sunspec.org

Start End # R/W Name Type Units Scale Factor Contents Description M/O

Next Block Another DID/Length Block/Data or EndOfSunSpecBlock DID value 0xFFFF End of Map M

Last Regi ster EndofSunSpecBlock length 0x0000 End of Map M

Figure 7: Common Modbus Model Mapping

String Combiner Model Specification 1 www.sunspec.org

Document #: A12030-1.2 Status: Approved Version 1.2 Approval date: 06-19-2013

String Combiner Model SunSpec Alliance Specification

John Blair, John Nunneley, Steve Lewis, Rafal Pabich, Alessio Costantini, Aaron McNally, Aaron Parker, Lynn Linse, Lior Handelsman, Yaron Binder, Ronnie Petterson, Bob Schmitt, Matthew Perry, Bryan Thomas, Peter Rexelius, Steve Drouilhet, Martin Beran, Bob Fox, Cliff Baumann

This document describes the string combiner model and is an approved SunSpec Alliance interoperability specification

String Combiner Model Specification 2 www.sunspec.org

All other copyrights and trademarks are the property of their respective owners.

License Agreement and Copyright Notice This document and the information contained herein is provided on an "AS IS" basis and the SunSpec Alliance DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY

IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR

PURPOSE.

This document may be used, copied, and furnished to others, without restrictions of any kind, provided that this document itself may not be modified in anyway, except as

String Combiner Model Specification 3 www.sunspec.org

Revision Date Reason

1.0 06-19-2013

1.1 JKN: Reflect 401,402 models superseded by

403,404

1.2 09-29-2014 Change to new SunSpec document format

String Combiner Model Specification 4 www.sunspec.org

The SunSpec Alliance is a trade alliance of developers, manufacturers, operators and service providers, together pursuing open information standards for the distributed energy industry.

SunSpec standards address most operational aspects of PV, storage and other distributed energy power plants on the smart grid—including residential, commercial, and utility-scale systems— thus reducing cost, promoting innovation, and accelerating industry growth.

Over 70 organizations are members of the SunSpec Alliance, including global leaders from Asia, Europe, and North America. Membership is open to corporations, non-profits, and individuals.

For more information about the SunSpec Alliance, or to download SunSpec specifications at no charge, please visit www.sunspec.org.

About the SunSpec Specification Process SunSpec Alliance specifications are initiated by SunSpec members desiring to establish an industry standard for mutual benefit. Any SunSpec member can propose a technical work item.

Given sufficient interest and time to participate, and barring any significant objections, a workgroup is formed and its charter is approved by the board of directors. The workgroup meets regularly to advance the agenda of the team.

The output of the workgroup is generally in the form of an Interoperability Specification. These documents are considered to be normative, meaning that there is a matter of conformance required to support interoperability. The revision and associated process of managing these documents is tightly controlled. Other documents are informative, or make some recommendation with regard to best practices, but are not a matter of conformance. Informative documents can be revised more freely and frequently to improve the quality and quantity of information provided.

SunSpec Interoperability Specifications follow this lifecycle pattern of DRAFT, TEST, APPROVED and SUPERSEDED.

String Combiner Model Specification 5 www.sunspec.org

1. INTRODUCTION

2. STRING COMBINER DEVICE BLOCK

3. COMBINER AND INPUT STRING EVENT FLAG VALUES

4. MODBUS REGISTER MAPPINGS

4.1 BASIC String Combiner Modbus Mapping

4.2 ADVANCED String Combiner Modbus Mapping

String Combiner Model Specification 6 www.sunspec.org

This SunSpec Alliance Interoperability Specification describes the data models and Modbus register mappings for string combiner devices used in Photovoltaic systems. The specification is broken into two sections: A basic device map and an advanced device map. Both maps may contain any number of combiner inputs and are therefore variable in length. Combiner units that support environmental measurements should include an appropriate block from the SunSpec Environmental Models specification.

Implementations should leave unused or unsupported datapoints set to the “not implemented” value specified in the SunSpec Common Model. For example, the Not Implemented value for a 16 bit signed integer is 0x8000.

2. STRING COMBINER DEVICE BLOCK

The following data elements are provided to describe string combiners (SC). This model supports a variable number of string combiner inputs.

• C_SunSpec_DID – A well-known value that uniquely identifies this block as a basic

(401) or advanced string combiner block (402).

• C_SunSpec_Length – The length of the string combiner block in registers.

• SC_DC_xxxx –DC values.

• SC_Event_xxxx – Event Flags

• SC_Input_xxxx – Input values

3. COMBINER AND INPUT STRING EVENT FLAG

VALUES

The string combiner specific flags are defined here. Any number of events may be active at the same time, and as a result the SC_Event value is implemented as a bit-map. The SC_Event field applies to the Combiner as a whole while the SC_Input_Event field applies to the specific string combiner input. Events at the SC_Input_Event level are logically OR’d to produce the corresponding SC_Event value. Users can trigger on the combiner level SC_EVENT and then drill down to the SC_Input_Event level to determine which string(s) are at fault. The bit-map values specifically called out as SC_EVENT_COMBINER_ only apply to the combiner unit as a whole.

Event Name Flag Value Description SC_EVENT_LOW_VOLTAGE 0x00000001 Low voltage detected SC_EVENT_LOW_POWER 0x00000002 Low power detected SC_EVENT_LOW_EFFICIENCY 0x00000004 Low efficiency detected SC_EVENT_CURRENT 0x00000008 Current out of range SC_EVENT_VOLTAGE 0x00000010 Voltage out of range SC_EVENT_POWER 0x00000020 Power out of range SC_EVENT_PR 0x00000040 Performance ratio out of range SC_EVENT_DISCONNECTED 0x00000080 Disconnect switch is open

String Combiner Model Specification 7 www.sunspec.org

Event Name Flag Value Description SC_EVENT_FUSE_FAULT 0x00000100 Input fuse blown on one or more inputs. See SC_Input_Events for details.

SC_EVENT_COMBINER_FUSE_FAULT 0x00000200 Combiner output fuse blown.

SC_EVENT_COMBINER_CABINET_OPEN 0x00000400 Combiner cabinet open SC_EVENT_COMBINER_TEMP 0x00000800 Combiner internal temp out of range.

SC_EVENT_GROUNDFAULT 0x00001000 Groundfault detected SC_EVENT_REVERSED_POLARITY 0x00002000 Reversed polarity detected SC_EVENT_INCOMPATIBLE 0x00004000 Incompatible input detected SC_EVENT_COMM_ERROR 0x00008000 Subsystem

Communication Error SC_EVENT_INTERNAL_ERROR 0x00010000 Internal Self –Test

Failed. See SC_Vendor_Status for details

SC_EVENT_THEFT 0x00020000 Theft detected SC_EVENT_ARC_DETECTED 0x00040000 Arc detected.

SC_EVENT_RESERVED 0xFFF80000 Reserved for SunSpec

4. MODBUS REGISTER MAPPINGS

4.1 BASIC String Combiner Modbus Mapping

The Basic String Combiner Modbus Mapping is a variable length model. The model supports combiners of any number of inputs. Combiner level readings provide combined values for Current, AmpHours, Voltage, Status, and Events. Individual string readings are provided for the Current and Events.

<See PICS.xls or smdx_00403.xml>

4.2 ADVANCED String Combiner Modbus Mapping

The Advanced String Combiner MODBUS Mapping is a variable length model. The model supports combiners of any number of inputs. Advanced measurements and metered values for Voltage, Power, Energy, and Performance Ratio are provided at the Combiner and Input String level.

Performance Ratio is defined to be the Actual Performance / Expected Performance. Actual Performance is measured and metered by the device. The Expected Performance is calculated based on a variety of factors. The method of calculation for the Expected and Actual Performance is not part of this specification and is vendor specific.

<See PICS.xls or smdx_00404.xml>

Panel Model Specification 1 www.sunspec.org

Document #: A12024-1.1 Status: Approved Version 1.1 Approval date: 01-02-2012

Panel Model

Yaron Binder, John Nunneley, Greg Madianos, Michael Klobe, Richard Duong Aaron McNally, Alessio Constantini, Roberto Orozco, Rafal Pabich

This document describes the Module (panel level) model and is an approved SunSpec Alliance interoperability specification.

Panel Model Specification 2 www.sunspec.org

All other copyrights and trademarks are the property of their respective owners.

License Agreement and Copyright Notice This document and the information contained herein is provided on an "AS IS" basis and the SunSpec Alliance DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY

IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR

PURPOSE.

This document may be used, copied, and furnished to others, without restrictions of any kind, provided that this document itself may not be modified in anyway, except as

Email: info@sunspec.com

Panel Model Specification 3 www.sunspec.org

Revision Date Reason

1.0 01-02-2012

1.1 09-19-2014 Change to new SunSpec document format

Panel Model Specification 4 www.sunspec.org

The SunSpec Alliance is a trade alliance of developers, manufacturers, operators and service providers, together pursuing open information standards for the distributed energy industry.

SunSpec standards address most operational aspects of PV, storage and other distributed energy power plants on the smart grid—including residential, commercial, and utility-scale systems— thus reducing cost, promoting innovation, and accelerating industry growth.

Over 70 organizations are members of the SunSpec Alliance, including global leaders from Asia, Europe, and North America. Membership is open to corporations, non-profits, and individuals.

For more information about the SunSpec Alliance, or to download SunSpec specifications at no charge, please visit www.sunspec.org.

About the SunSpec Specification Process SunSpec Alliance specifications are initiated by SunSpec members desiring to establish an industry standard for mutual benefit. Any SunSpec member can propose a technical work item.

Given sufficient interest and time to participate, and barring any significant objections, a workgroup is formed and its charter is approved by the board of directors. The workgroup meets regularly to advance the agenda of the team.

The output of the workgroup is generally in the form of an Interoperability Specification. These documents are considered to be normative, meaning that there is a matter of conformance required to support interoperability. The revision and associated process of managing these documents is tightly controlled. Other documents are informative, or make some recommendation with regard to best practices, but are not a matter of conformance. Informative documents can be revised more freely and frequently to improve the quality and quantity of information provided.

SunSpec Interoperability Specifications follow this lifecycle pattern of DRAFT, TEST, APPROVED and SUPERSEDED.

Panel Model Specification 5 www.sunspec.org

Table of Figures Nomenclature

1. INTRODUCTION

2. RELATIONSHIP OF THIS SUNSPEC MODEL TO MODULES WITH

MICROINVERTERS

3. DEVICE BLOCK STRUCTURE AND USAGE – WITH AND WITHOUT AN

AGGREGATOR

4. AGGREGATOR STATUS VALUES

5. MODULE STATUS VALUES

6. MODULE (AND AGGREGATED) EVENT FLAG VALUES

7. MODULE (AND AGGREGATED) CONTROL VALUES

8. MODBUS REGISTER MAPPINGS

8.1 Aggregator Modbus Mapping

8.2 Module Modbus Mapping

Panel Model Specification 6 www.sunspec.org

Table 1: Aggregator status values Table 2: Module status values Table 3: Module and Aggregated event flag values Table 4: Module and aggregated control values Table 5: Aggregator Modbus mapping Table 6: Module Modbus mapping Table 7: Module Modbus mapping

Panel Model Specification 7 www.sunspec.org

Abbreviation Meaning A_control Aggregator control

A_event Aggregated event

A_status Aggregator operational status

I_event Inverter event

P_control Module-specific control

P_event Optimized event

P_status Individual module operational status

Panel Model Specification 8 www.sunspec.org

This SunSpec Alliance Interoperability Specification describes the data models and Modbus register mappings for solar module devices used in Photovoltaic systems. The module has electronics connected to it that can monitor and/or optimize it individually.

In a single installation there might be 1 to 1000s modules connected to a single inverter/data-logger. Module level solutions include a communication interface that might aggregate data from more than one module onto a single Modbus address.

The common model of SunSpec is expanded to allow the use of many modules on the same Modbus address.

2 devices are defined in the document –

• A basic device map for a module using floating point registers

• A basic device map for a module using integer registers

The device numbers are:

501 – Module device (floating point model)

502 – Module device (integer model) An optional aggregator that allows for many modules to be connected to the same Modbus address is also defined SunSpec common model is to be changed to allow the use of the Aggregator in a general way to aggregate any device and mix of devices on the same Modbus address.

The aggregator device number will be 002 Implementations should leave unused or unsupported datapoints set to the “not implemented” value specified in the SunSpec Common Model. For example, the Not Implemented value for a 16 bit signed integer is 0x8000.

2. RELATIONSHIP OF THIS SUNSPEC MODEL TO

MODULES WITH MICROINVERTERS

Microinverters devices are defined in the Inverter Modules of SunSpec.

The Aggregator device defined in this document can also be used for aggregating many Inverter Modules to the same Modbus address. In that case, the device block structure will be similar to what is described in the “device block structure and usage” chapter except for the fact that many inverter devices (101, 102, 103…) will be used instead of module devices (501 and 502)

In case an aggregator is used to aggregate many microinverters the aggregated event register (A_event) will be as defined in the inverter model. For this reason, whenever possible, the mapping of module and optimizer events (P_event) follow the same bit mapping as the inverter mapping (I_event)

Panel Model Specification 9 www.sunspec.org

3. DEVICE BLOCK STRUCTURE AND USAGE – WITH

AND WITHOUT AN AGGREGATOR

Each Module Block will be preceded with a Common Block header. The module specific Model, Manufacture information, Version and Serial Number are described in the common block.

There are 2 optional block structures.

1. One module on the same address

Common Block

Device

End Block

2. Multiple modules on the same address

Each Modbus address includes and optional aggregator indicating the number of modules mapped to this address, the mapping status and an aggregation of the modules events that are mapped into this address.

If the mapping is changed since last read, the aggregator will increment the A_Update_Number register. If this register is not incremented then direct access to a specific module offset will result in reading the same module every time

Common Block

Aggregator device (600)

Common Block

Device

Common Block

Device

Common Block

Device

End Block

Note: The aggregator device may be used to aggregate any device type defined in SunSpec.

For example, if a u-inverter is used on each module the mapping will use the inverter device models (101,102,103). If a power optimizer is used the device mapped will be 501 or 502

Panel Model Specification 10 www.sunspec.org

4. AGGREGATOR STATUS VALUES

The A_Status values apply to the Aggregator operational status and does not describe the status of the devices mapped to it.

By definition the aggregator may exist in only one operating state at any given time. Reflecting this property, the A_Status datapoint is implemented as an enumerated type. Manufacturers should describe their operational state using the closest applicable A_Status value at all times.

Status Name Value Description A _STATUS_OFF 1 Off – not communicating with aggregated devices A_STATUS_ON 2 On - communicating with aggregated devices A_MEMORY_FULL 3 Aggregator memory full / too many devices used

A_FAULT_OTHER 4 See Vendor Status for details

Table 1: Aggregator status values

5. MODULE STATUS VALUES

The P_Status values apply to the individual module. . The module specific values are defined here.

• P_Status_ – Status code associated with the operational state of the device. By definition the module may exist in only one operating state at any given time. Reflecting this property, the P_Status datapoint is implemented as an enumerated type.

Manufacturers should describe their operational state using the closest applicable P_Status value at all times.

Status Name Value Description P_STATUS_OFF 1 Off P_STATUS_SLEEPING 2 Sleeping (auto-shutdown) or panel is at low/safe output power/voltage – P_STATUS_STARTING 3 Stating up or ON but not producing power - pane might have high voltage but is not supplying power

P_STATUS_MPPT 4 Tracking MPPT power point

P_STATUS_THROTTLED 5 Forced power reduction / power De-rating

P_STATUS_SHUTTING_DOWN 6 Shutting down P_STATUS_FAULT 7 One or more faults exist

Panel Model Specification 11 www.sunspec.org

Status Name Value Description P_STATUS_STANDBY 8 Standby (service on unit) – unlike

“SLEEPING” in this mode the module might be a high (unsafe) output voltage or power

P_STATUS_TEST

Test mode

P_STATUS_OTHER 10 As defined in vendor specific

Table 2: Module status values

6. MODULE (AND AGGREGATED) EVENT FLAG

VALUES

The Module specific flags are defined here. Any number of events may be active at the same time, and as a result the P_Event value is implemented as a bit-field.

If using an Aggregator the aggregated events register (A_Event) events will be logically OR all P_Event registers mapped to it to produce an aggregated events register.. In other words A_EVENT will show all the events that a occurring in the modules below it. User will then be able to scan the mapping to find which module(s) have these events.

Whenever possible, the mapping of module and optimizer events follow the same bit mapping as the inverter mapping to allow the use of aggregators of microinverters.

For this reason, module events will not use (RESERVE) event bits that relate to grid connection in the inverter mapping

P_EVENT_GROUND_FAULT 0x00000001 Ground Fault P_EVENT_INPUT_OVER_VOLTAGE 0x00000002 DC input over voltage RESERVED 0x00000004 Reserved for microinverter compatibility P_EVENT_DC_DISCONNECT 0x00000008 DC disconnect open

RESERVED 0x00000010 Reserved for u-inverter compatibility

RESERVED 0x00000020 Reserved for u-inverter compatibility

P_EVENT_MANUAL_SHUTDOWN 0x00000040 Manual shutdown

P_EVENT_OVER_TEMPRATURE 0x00000080 Over Temperature RESERVED 0x00000100 Reserved for microinverter compatibility

Panel Model Specification 12 www.sunspec.org

RESERVED 0x00000200 Reserved for microinverter compatibility RESERVED 0x00000400 Reserved for microinverter compatibility RESERVED 0x00000800 Reserved for microinverter compatibility P_EVENT_BLOWN_FUSE 0x00001000 Blown Input Fuse

P_EVENT_UNDER_TEMPRATURE 0x00002000 Under Temperature

P_EVENT_MEMORY_LOSS 0x00004000 Generic Memory or Communication error.

P_EVENT_ARC_DETECTION 0x00010000 Arc Detection P_EVENT_THEFT_DETECTION 0x00020000 Theft Detection P_EVENT_OUTPUT_OVER_CURRENT 0x00040000 Output Over Current P_EVENT_OUTPUT_OVER_VOLTAGE 0x00080000 DC Output Over Voltage P_EVENT_OUTPUT_UNDER_VOLTAGE 0x00100000 DC output under Voltage

P_EVENT_TEST_FAILED 0x00200000 Last Self Test Failed, see vendor event for details

RESERVED 0xFF600000 Reserved for SunSpec Table 3: Module and Aggregated event flag values

7. MODULE (AND AGGREGATED) CONTROL VALUES

The Module specific controls (P_CONTROL) are defined here. Each module can have a single enumerated control value. In some cases a control value will be needed in which case P_CONTROL_VALUE will be needed

If using an aggregator changing A_CONTROL will change the control to all devices mapped to it

Control Name Value P_CONTROL_V ALUE Description

P_control_no_cont rol 0 N.A. No control value

P_Control_Automa tic 1 N.A. Allow normal operation

P_Control_Force OFF 2 N.A. Force module to OFF or safe mode

P_Control_Test 3 Test number Enter test mode

P_Control_Throttle 4 Percent of peak output power of

CONTROL_VALUE register is % of max rated power of the optimizer.

Panel Model Specification 13 www.sunspec.org the device (0- 100%)

Table 4: Module and aggregated control values

8. MODBUS REGISTER MAPPINGS

Each field is either Mandatory/Optional/Conditional according to the M/O/C column.

Conditional registers are dependent the existence of optional registers as described in the last column

8.1 Aggregator Modbus Mapping

The Aggregator mapping is a fixed length model.

Start Offset

End Offset Size R/

W Name Type Units Sca le Fac tor

Contents Description M/O/C

1 1 1 R C_SunSpec_ DID unit16 DID N/A 002

Uniquely identifies this as a BASIC SunSpec Aggregator Modbus Map M

2 2 1 R C_SunSpec_ Length unit16 Registers N/A 14 Fixed Number M

3 3 1 R A_Devices unit16 DID N/A Number DID of the aggregated devices M

4 4 1 R A_Count unit16 Number N/A Counter Number of devices connected to this aggregator M

5 5 1 R A_Update_N umber unit16 Number N/A Counter

Incrementing number each time mapping is changed. If number is not changed from last reading then direct access to a specific offset will result in reading the same aggregated device as before M

6 6 1 R A_Status uint16 Enumerated N/A Status Aggregator status code M

7 7 1 R A_Status_Ve ndor uint16 Enumerated N/A Status Aggregator vendor specific status code O

8 9 2 R A_Event uint32 Bitfield N/A Event Aggregation of event flags M

10 11 2 R A_Event_Ve ndor uint32 Bitfield N/A Event

Aggregation of vendor specific event flags O

12 12 1 R/ W A_Control uint16 Enumerated N/A Control Control register to all devices O

Panel Model Specification 14 www.sunspec.org

Start Offset

End Offset Size R/

W Name Type Units Sca le Fac tor

Contents Description M/O/C

13 14 2 R/ W

A_Control_V endor unint32 Enumerated N/A Control Vendor specific control register O

15 16 2 R/ W

A_Control_V alue unint32 Enumerated N/A Control

Numerical Value used by control register

C – must be used if A_cont rol is used

Table 5: Aggregator Modbus mapping

8.2 Module Modbus Mapping

The Module Modbus Mapping is a fixed length model.

2 models are defined.

501 – Floating point registers are used to represent the measurements 502 – Integer registers are used to represent the measurements with scale factors

Start Offset

End Offset Size R/

W Name Type Units Scale Factor Contents Description M/O

/C

1 1 1 R C_SunSpec_ DID unit16 DID N/A 501

Uniquely identifies this as a BASIC SunSpec Panel Modbus Map M

2 2 1 R C_SunSpec_ Length unit16 Registers N/A 31 Fixed Number M

3 3 1 R P_Status uint16 Enumerated N/A Status Module level status code M

4 4 1 R P_Status_Ve ndor uint16 Enumerated N/A Status

Module level vendor specific status code O

5 6 2 R P_Event uint32 Bitfield N/A Event Module level event flags M

7 8 2 R P_Event_Ve ndor uint32 Bitfield N/A Event

Module level vendor specific event flags O

9 9 1 R/ W P_Control uint16 Enumerated N/A Control Module level control O

10 11 2 R/ W

P_Control_V endor unint32 Enumerated N/A Control

Module level vendor specific control O

12 13 2 R/ W

P_Control_V alue int32 value N/A Control

Module level vendor specific control O

14 15 2 R P_Data_Tim estamp uint32

GMT

Seconds from 1970

N/A Metered Time of measurement - "timen" format O

16 17 2 R P_DC_Outpu float32 Amps N/A Measur Module Output O

Panel Model Specification 15 www.sunspec.org

Offset

End Offset Size R/

W Name Type Units Scale Factor Contents Description M/O

/C t_Current ed current

18 19 2 R P_DC_Outpu t_Voltage float32 Volts N/A Measur ed Module Output voltage O

20 21 2 R P_DC_Outpu t_Energy float32 Watts*Hour N/A Metered Module Produced

Energy - Daily O

22 23 2 R P_DC_Outpu t_Power float32 Watts N/A Measur ed Module Power O

24 25 2 R P_Temp float32 Celsius N/A Measur ed Module Power O

26 27 2 R P_DC_Input_ Current float32 Amps N/A Measur ed

Module Input current - Input registers to be used for optimizers O

28 29 2 R P_DC_Input_ Voltage float32 Volts N/A Measur ed

Module Input voltage - Input registers to be used for optimizers O

30 31 2 R P_DC_Input_ Energy float32 Watts*Hour N/A Metered

Module Input Produced Energy - Daily - Input registers to be used for optimizers O

32 33 2 R P_DC_Input_ Power float32 Watts N/A Measur ed

Module Power - Input registers to be used for optimizers O

Table 6: Module Modbus mapping

Panel Model Specification 16 www.sunspec.org

Offset

End Offset Size R/

W Name Type Units Scale Factor Contents Description

M/ O/ C

1 1 1 R C_SunSpe c_DID unit16 DID N/A 502

Uniquely identifies this as a

BASIC

SunSpec Panel Modbus Map

M

2 2 1 R C_SunSpe c_Length unit16 Registers N/A 28 Fixed

Number M

3 3 1 R P_DC_Curr ent_SF int16 SF_V N/A Configured DC Current

Scalefactor C if P_DC_Outpu t_Current or P_DC_Input_ Current are supported

4 4 1 R P_DC_Volt age_SF int16 SF_I N/A Configured DC Voltage

Scalefactor C if P_DC_Outpu t_Voltage or P_DC_Input_ Voltage are supported

5 5 1 R P_DC_Pow er_SF uint16 SF_P N/A Configured DC Power

Scalefactor C if P_DC_Outpu t_Energy or P_DC_Input_ Energy are supported

6 6 1 R P_DC_Ene rgy_SF uint16 SF_E N/A Configured DC Energy

Scalefactor C if P_DC_Outpu t_Power or P_DC_Input_ Power are supported

7 7 1 R P_Status uint16 Enumerat ed N/A Status

Module level status code

M

8 8 1 R P_Status_V endor uint16 Enumerat ed N/A Status

Module level vendor specific status code

O

9 10 2 R P_Event uint32 Bitfield N/A Event Module level event flags

M

Panel Model Specification 17 www.sunspec.org

Offset

End Offset Size R/

W Name Type Units Scale Factor Contents Description

M/

11 12 2 R P_Event_V endor uint32 Bitfield N/A Event

Module level vendor specific event flags

O

13 13 1 R/ W P_Control uint16 Enumerat ed N/A Control Module level control

O

14 15 2 R/ W

P_Control_ Vendor uint32 Enumerat ed N/A Control

Module level vendor specific control

O

16 17 2 R/ W

P_Control_ Value int32 value N/A Control

Numerical Value used by control register

C to be used if P_control is used

18 19 2 R P_Data_Ti mestamp uint32

GMT

Seconds from 1970

N/A Metered

Time of measureme nt - "timen" format

O

20 20 1 R P_DC_Out put_Current int16 Amps _SF_

I Measured Module Output current

O

21 21 1 R P_DC_Out put_Voltag e

Int16 Volts _SF_ V Measured

Module Output voltage

O

22 23 2 R P_DC_Out put_Energy uint32 Watts*Ho ur

_SF_

E Metered

Module…