The goal of the SunSpec Alliance is to create a common language that all renewable energy component manufacturers can adhere to in order to enable interoperability amongst all compliant technologies. In doing so, the SunSpec Alliance is publishing a series of specifications, initially built upon Modbus® standards, which are intended to remove the barriers that currently prevent the industry from being able to integrate distributed photovoltaic (PV) power generation systems cost-effectively and on a large-scale basis.
SunSpec Specifications Now Available for Public Comment
The first SunSpec specifications are now available for public comment, providing all interested individuals and organizations the opportunity to review and provide feedback on the draft specifications before they are released in final form. Industry stakeholders are encouraged to review the specifications and provide candid feedback by posting to the blog below. Click here to download the SunSpec specifications.
Specifications available for download include:
- Common Device Model
- Environmental Models
- Meter Models
- Inverter Models
Modbus® is a registered trademark of the Modbus Organization, Inc.
PDF format is fine for some things, but it would be convienient to have your spec tables in .xls format for incorporation into other working documents.
Yes, the last poster is missing that this is NOT yet-another standard bus. The world suffers under too many already & a vehicle bus is likely the last one I’d want to invest in.
This is an interchange standard, so a client/master device owned by company XYZ wishes to collect data remotely from a solar device owned by company ABC. Forcing hardware changes in either company is unacceptable. Use of Modbus at the “local bus” level is 100% irrelevant – nothing stops a user from wanting BACNet or LONworks or ProfiNET.
Did I miss something? Like what is the system topology? Physical layer? Connectors/cabling? Are you really thinking master/slave Modbus? If there is a smart meter, a fixed location user interface, a wireless user interface, an internet gateway, etc., who is the master? Or does all that happen on the other side of some Sunspec Master Device we’re going to have to work through? Via yet another protocol?
Seems to me something more like J1939/ISObus, where all manner of sensor/actuator/interface devices can exchange information or ignore each other as appropriate, would be a better model. But apparently you’re well past asking for comment on basic topology…
Supported physical layers include RS-485 and 802.X (wired and wireless Ethernet). The primary aspect of standardization we’re working on is data representation.
RS-486 appears to be a road tunnel in Brazil. I suspect you mean RS-485? Which IMHO is the serial interface with the most possible ways for two devices to end up incompatible… Ethernet is good, but then why limit your data representation to a single-master topology? I would hope that any ZigBee device would be able to interact with my energy production equipment.
Ah, the dangers of replying late at night. I did mean RS-485 and have corrected the comment (with no disrespect to the Brazilian road department).
There is no intent to limit data representation with a single master topology. There is, on the other hand, an intent to explicitly agree on topologies–and right now the agreement seems to be on RS-485, Ethernet, and its derivatives. If you want other topologies, join a SunSpec working group and convince your peers to go along. This effort is all about open collaboration and interoperability.
It would be nice if there was an optional map higher up in modbus memory with true 32-bit floats. Some inverters may not be able to manage IEEE floats, but a growing number of embedded systems have 32-bit processors and can handle IEEE float. I’d suggest the Modicon form of low-word in first of two registers. This block/map would be 100% optional, so clients/masters could read from either.
The way the SF/Scale factors are bundled will make OPC and client configuration more complex, and in a few cases require software changes.
[...] To download the SunSpec: Modbus Specification, click here. [...]
The “Click here to download the SunSpec MODBUS specifications” should really lead to a page with the specifications, not a registration page.
If you really want to elicit comment, why hide the specifications behind a registration wall?
The specifications are openly available. We are keenly interested in who is downloading them as they represent a potential new member. Individuals not wishing to be identified can register anonymously.
The SunSpec Alliance is developing a standard set of common register values
for equipment used in renewable systems utilizing the Modbus communication
standard. Equipment targeted for specification development include:Modbus
Standard Overview, Modbus Standard Register Maps.
- Robb Henshaw
All SunSpec devices will support a Common Block of data elements
And overall structure. These common elements support needed operations for
Device identification and asset management. The Common Block is followed by
one or more Device Specific Blocks. These contain the measured values,
status, alarms, and other values that make up the device type.
- John Nunneley
The Spec is really helpful for in defining standards for inverter
models. I would strongly suggest you read this section.
- Barry Hasser