25.12.2012 Views

security profile for openadr - Open Smart Grid - OpenSG - UCA ...

security profile for openadr - Open Smart Grid - OpenSG - UCA ...

security profile for openadr - Open Smart Grid - OpenSG - UCA ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

2 176 Functional Analysis<br />

177<br />

178<br />

179<br />

180<br />

181<br />

182<br />

183<br />

184<br />

185<br />

186<br />

187<br />

188<br />

189<br />

190<br />

191<br />

192<br />

193<br />

194<br />

195<br />

196<br />

197<br />

198<br />

199<br />

The purpose of the functional analysis is to define a clear picture of the scope,<br />

architecture, and functionality of <strong>Open</strong> Automated Demand Control (<strong>Open</strong>ADR)<br />

systems, as addressed by this <strong>security</strong> <strong>profile</strong>. The implementation of <strong>Open</strong>ADR system<br />

functions varies in terms of function, scope, and technology from among different market<br />

and system offerings and deployments. However, this <strong>profile</strong> approaches the problem by<br />

defining a set of abstract roles that capture essential functionality that may be realized<br />

through a variety of implementations. This <strong>profile</strong> defines roles in such a way that the<br />

logical architecture and use case functionality may be used to represent a wide variety of<br />

real-world implementations.<br />

By way of background, the following steps were per<strong>for</strong>med in the functional analysis:<br />

1. Review of the existing documents that define the overall <strong>Open</strong>ADR process,<br />

paradigm, and design (as defined in Appendix E References).<br />

2. Define abstract roles that characterize elements of <strong>Open</strong>ADR Systems. Roles are<br />

neutral to implementation and vendor, and capture the essence of common<br />

functionality without the details of particular applications. The resulting roles are<br />

presented in Section 2. Their relationships with each other (topologically) are<br />

presented in Section 2.1.<br />

3. Define use cases describing how the roles interact to implement <strong>Open</strong>ADR<br />

functionality. The use cases are modular in nature, which allows organizations to<br />

determine which use cases are relevant to their deployments. They also capture<br />

raw functionality, without the inclusion of <strong>security</strong> controls, which ensures that no<br />

pre-existing <strong>security</strong> controls are assumed and allows different controls to be<br />

applied without bias. The resulting use cases are presented in Section 2.4.<br />

SECURITY PROFILE FOR OPENADR<br />

Version – 0.02<br />

<strong>UCA</strong> International Users Group December 15, 2011<br />

16

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!