Smart Grid Architecture Development - Institute Of Electrical And .

1y ago
1.63 MB
38 Pages
Last View : 1m ago
Last Download : 5m ago
Upload by : Gia Hauser

Smart Grid Architecture DevelopmentIEEE Power & Energy Society SF ChapterElectric Grid Modernization (Smart Grid) WorkshopOctober 17, 2011San Francisco, CaliforniaJoe Hughes, CEOReef Energy Systems, LLC

SOME DEFINITIONSArchitecture: The Structure of Components, their relationships,and the principles and guidelines governing their design andevolution over time**DoD Integrated Architecture Panel, based on IEEE Std 610.12

DEVELOPING ARCHITECTURE FOR THE SMART GRID Why: Business and Technical Drivers BehindArchitecture Development What: Architecture Development: Some Basics How: Smart Grid Architecture DevelopmentProcesses

Drivers for Architecture developmentMore automation equipment is required to beintegrated and interwork Across more functional and department“boundaries” with more robust implementations against futureobsolescence to be operated seamlessly into anenterprise/industry wide system. to be well managed and adequately secure and all to be supported by fewer people

TODAY’S SITUATION: “SMART” COMMUNICATION ANDAUTOMATION SYSTEMS “Islands of Automation”Little IntegrationAcross the IndustryProprietarySystemsCommunication SystemsWhere’s theArchitecture?No Integration withConsumer Equipment


Business Drivers For Open Standards Capital Cost Savings– Competitive Procurement of intelligentequipment through Standards and OpenSystems– Multi-vendor support and avoidance of singlevendor “lock-in”– Extensible and Scalable “Industry-wide” Life-Cycle Cost Savings– More uniform Standards based systems– Extensible for the Future– More capable systems, easier to maintain– Immune to single vendor limitations Security Policy Implementation

Open Standards Are Not Enough WithoutArchitecture Many existing “solutions” are not solutions cannot be integrated with other systems cannot be scaled up to large numbers lack critical capabilities such as managing securitypolicies consistently across domains devices and networks cannot be effectivelymanaged on the required scale data cannot be effectively managed on therequired scales systems cannot be maintained at reasonablecosts over the long term cannot be effectively extended for future needs

General Economic Drivers For ArchitectureOpen SystemsImplementationsCapital CostReductionsSystems Engineering andArchitecture MethodsLife Cycle Cost Robust DesignsReductionsEnablingInfrastructuresDecrease CostsCommunicationsAsset sEnable ConsistentIncrease ValueManagement/Security

Architecture Development is Required to EffectivelyIntegrate Open Standards Multi-vendor procurement of interoperable equipment (Capital ) integration of equipment from different vendors.(Avoid singlevendor “lock-in”) Avoid functional lock-in, minimize obsolescence Save life-cycle costs: system upgrades and maintenance (O&M ) Leverage available Human Resources Consistency in minimum sets of critical requirements Avoiding “Forklift Upgrade” (O&M ) Bottom Line: Architecture Development is Requirement for theSmart Grid to Exist

Why do an architecture? Necessary to manage complexity More completely and accurately link: goals, business models,drivers and stakeholders with supporting technical developmentand management processes Provides approaches to enterprise and industry leveldevelopment and documentation Enables understanding of synergies/problems that lower levelviews miss Primary approach for consistently establishing and implementingsecurity policies across the enterprise/industry Currently there is no complete open architecture for smart grid

ARCHITECTURE IS CRITICAL TO MEET SPECIFIC GOALS“Section 1305(d) of the Energy Independence and Security Act of 2007 directs theCommission to institute a rulemaking proceeding to adopt such standards andprotocols as may be necessary to insure smart-grid functionality andinteroperability in interstate transmission of electric power, and regional andwholesale electricity markets once it is satisfied that the work of the NationalInstitute of Standards and Technology has led to “sufficient consensus” on smartgrid interoperability standards.”UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY COMMISSION[Docket No. RM11-2-000] Smart Grid Interoperability Standards(Issued July 19, 2011)

ARCHITECTURE DEVELOPMENT IS THE ONLY WAY THAT SPECIFICSTAKEHOLDER AND POLICY GOALS CAN BE ACHIEVED Security Policy Management Systems Management Industry Level Integration– ISO/RTO Operations across ISO lines Wide Area Situational Awareness– Customer End Use Equipment Integration Electric Vehicles Heating, Ventilation, and Air Conditioning Appliances Other Other

PRESENTATION OVERVIEW Why: Business and Technical Drivers BehindArchitecture Development What: Architecture Development: Some Basics How: SGIP Smart Grid Architecture Committee

ARCHITECTURE IS NECESSARY FOR LARGE SCALE DEVELOPMENT Standards, User Implementation Agreements, Technology Guidelinesand other documents are important building blocks but are insufficientin themselves for large scale integrated systems like smart grid Architecture provides the integration necessary to bring together the fullvision of the intended system– Identify key domains and domain interfaces– Identify where open standards need to be harmonized, unified orotherwise integrated– Identify and manage how legacy systems should be integrated Architecture is necessary to ensure a minimum levels of completeness insystem requirements including the following categories:– Systems and Network Management– Security Management– Applications Development– Requirements Traceability to Identified Stakeholder Needs

“IT”Power procurementMarket operationsRegional TransmissionOperatorDistribution Control CenterExternal corporationsPower ructureDataintegrationApplicationsArchitecture: Developing and Managing IntegrationAcross the Greater Smart Grid IndustryLarge Scale GenerationintegrationTransmission AMIDER integration“PE”

Characteristics of differentENABLE INTEGRATION ACROSS DIFFERENT “ENVIRONMENTS”distributed computing icationDelayToleranceDelays ution“Soft”Real-timeShort delays aretolerableDatabaseaccess overa LAN“Hard”Real-timeDelays can failan application, delaysmust be tions

Architecture Development FocusBusiness &Industry GoalsTechnical EnterpriseArchitectureDomain ArchitecturesData, communications andmanagement system architecture(s)Applied Technology and Components

DEVELOPING ARCHITECTURE FOR THE SMART GRID Why: Business and Technical Drivers BehindArchitecture Development What: Architecture Development: Some Basics How: SGIP Smart Grid Architecture Committee

SYSTEMS ENGINEERING: REQUIREMENTS DEVELOPMENT Requirements Types– Functional Describe the functions of the application: What theApplication Should do for the end-user– Non Functional Describe the supporting functions to enable theapplication to properly execute Also includes systems and networking management aswell as security

RECOMMENDED APPROACHES: DEVELOP FUNCTIONAL AND NONFUNCTIONAL REQUIREMENTS TOGETHER Applications:– System must support the requirements coming from powerengineering needs Systems and Network Management:– Installed communications networks and intelligent equipment mustbe able to be observed and maintained Security:– System must include adherence to security policies and includesystem “hardening” as well as managing residual risk

REQUIREMENTS SOURCES From Existing Systems Documentation System and Technology Plans Stakeholder Interaction– Power Engineers– Systems Administrators– Security Personnel Standards and Consortia Industry Plans and Documents For Future Systems– EPRI Reports and Project Results Ideally:– A combination of Text and Graphical Representation– Standardized Terminology to the extent possible– Use of Computer Based Tools and a “Model” of systemcharacteristics

REQUIREMENTS DEVELOPMENT: USE CASE AND REQUIREMENTSDEVELOPMENT TEMPLATE“Word” DocumentSpreadsheetUsed for narrativediscussionPerformanceLevel Details

Conversion from Requirements to IndustryModels One Method“Use Case de Area ControlADARTPWide Area Mea DOMAImportWordTemplatesinto theCASE ToolCreate agraphicalrendering(UML)Computer Aided SystemsEngineering (CASE) Tool

ARCHITECTURE HOW: ENABLES MORE COMPLETEREQUIREMENTS DEVELOPMENT Necessary to encompass different stakeholder perspectives– Applications Development– Security– Technical Management (includes Life-cycle management) Thorough Requirements are Critical for–––– Field Equipment with limited resourcesForward looking and Robust Network and Physical Communications DesignsDeveloping Robust Standards leading to robust system designsDeployments of field equipment must last 20 to 30 yearsConsequences of weak or incomplete requirements– Cost of incomplete requirements caught at design time .caught at implementationtime caught after deployment .

UNDERSTAND THE COMPLEXITIES WITHIN THE REQUIREMENTSReal-Time Pricing Enterprise Activity (RTP Function)Showing Interactions and Information Flows between ApplicationsMarket Operations SystemsEnergy Services Providers SystemsSubmit aggregatedenergy schedulesScheduleEnergy Database Aggregateenergyschedules Database Energy SchedulesManage AncillaryServicesAggregatedCustomer SchedulesSubmit ancillaryservices offersAggregateancillaryservicesbids/offers Database Ancillary ServiceBids/Offers Database Trigger calculationevery hourCalculateBaseRTP TimeOfDay Provide energyschedulesProvideforecast loadsMarketTimerAggregatedCustomer OffersMarket Interface Server Database CalculateRTP rate tables perCustomer Type Database Forecast PowerSystem ConditionsCustomer LoadForecastSend base RTP dataProvide ancillaryservice bids/offersBase RTP Data Database Forecast Loads Database CustomerGeneration OffersMarketTariffSecurity is majorconcernAudit RTPReceive weather dataWeatherExternal OverseersAvailability, highspeed, andaccuracy aremajor concernsSend powersystem data such asscheduled outagesSend powersystem data such asscheduled outagesTransmission Operations SystemsMonitorTransmissionPower SystemValidateCompliance Database Transmission PowerSystem DataSupmit DRgeneration offersAuditDataRegulatorsSubmit customerload forecastsAudit Customer-specificRTP Rate TablesAudit RTPValidate marketrules for RTPAuditorsConfiguration and mediaissues are major concernsDistribution Operations Systems Database Distribution PowerSystem DataMonitorDistributionPower SystemMulti-cast RTP toselected customer systemsCustomer Building Automation System powertype Transmission PowerSystem powertype Distribution PowerSystemAvailability, highspeed, andaccuracyDistributed Energy ResourcesMonitor DRControl DR PowerSystemDevice DistributedResources DataManage es and offers Database Customer-specificRTP rate table Human CustomerSet and reviewparametersTrigger load andgeneration forecastsOptimize load and DRoperations based on RTPSchedule DR generationSchedule loadsProvideload dataCreate load schedule Database DER Schedule powertype CustomerLoads Database Load schedule TimeOfDay ForecastTimer

Industry-Level Architecture Seeks toIntegrate Between StandardsFramework forManagement andSecurity rmonizationin progressIEC61850IEC61968MaturingANSIC12IEC61970IEC TC 13IEEE1459PartialEIA 600MissingIEEESCC31ASHRAESSPC 135IntegrationbetweenStandards(ProposedWork)

Gridwise Architecture to SGIP Priority Action Plan MapBusiness ProceduresPhysical Connection111System EvolutionDiscover & ConfigPerform, Reliable, ScaleSystem PreservationXaction & State MgmtLog & Audit1Security & PrivacyBusiness ObjectivesTime-Sync & SequenceResource IdentShared meaningEconomic/Regulatory2234Business Context3645Semantic Understanding59 10 117841612 13 146777881212121313131414148Syntactic Interoperability910Network Interoperability111215Network Interoperability1115151628

EXAMPLE ARCHITECTURE DEVELOPMENT TASK: DEVELOPCOMMON METER DATA MODELSIEC 61970/61968 Common Information Model(CIM) Enterprise Application SI/IEC Metering“FieldOperations”UCATM“Service Oriented Architecture”ProprietaryMetering BUCATMUCATMMeter DataManagementProprietaryMetering ACustomerCommunicationsUCATMUCATMUCAUCATMTMMeter MasterStation

Prototype “Gateway” Implementation: IntegratingMajor Metering, Utility Automation and BuildingAutomation StandardsAEIC Meter andService CommitteeC12.22CommModule10 Base TTCP/IP/ACSE/MMS(61850)EnergyServiceClient61850 toBacNetGatewayLogic levelC12.22End Device /COMM ModuleRS485BACnet gmtSystem

ARCHITECTURE PERSPECTIVES ON STANDARDS INTEGRATIONCommon Information Model (CIM)Application Integration SecurityUCA/IEC 61850Real-TimeEnvironmentMessage Broker “Integration Bus”Event HistoryWorkManagementGateway/SecurityLogical DeviceSubstationIED ServersServersAM/FM/GISSubstationAutomationkV 11.8LN: XCBRLN: CSWI

THREE LEGGED STOOL: NECESSARY INGREDIENTS FORSUCCESSFUL INTEROPERABLE SYSTEMS DEVELOPMENTInteroperable products and services1) Open standards:Protocols, testschemas, objectmodelsIEC TC57,ANSI C12,ASHRAE SPC1353) reference implementations:Developer Tools, StandardsImplementations and testimplementationsAMRTools, openAMI, 2) Involved UserGroup: InteroperabilityAgreements, Labeling,Testing, MarketingUCA International,BACnet Mfgs. Assoc.Assoc. of EdisonIlluminating Cos

INFRASTRUCTURE DEVELOPMENT ies/Users,Admin/MgmtUser GroupsField TestSmall/DevelopInteroperableEquipmentField TestLarge/DemoCommercialRollout

ARCHITECTURE PROVIDES A FRAMEWORK FOR CONSISTENCYWHERE IT IS NEEDED TO: Enable effective system designs, and documentation Develop, implement and manage security (and systemsmanagement) policies across the enterprise/industry Manage scale and scope of deployed systems Integrate systems across traditional operating boundariese.g. IT and Power Engineering Integrate systems across ownership boundaries e.g. utilitiesand customer systems Provide a systematic approach to Life-Cycle management ofsystems Provide a means of requirements traceability

SMART GRID ARCHITECTURE DEVELOPMENT Electric Power Research Institute: Utility Communications Architecture(UCA) 1.0 (1991) UCA 2.0 (1997) Natural Gas UCA (Joint between GRI and EPRI circa 1993) Water UCA (Joint between American Water Works RF and EPRI circa1994) MMS Forum (1992) UCA Forum (1996) UCA International UsersGroup IEEE Standards Coordination Committee 36 (1996) IEC Technical Committee 57 “Architecture Document” EPRI Integrated Energy and Communications System Architecture(IECSA) (2004) EISA Legislation (2007) SGIP Smart Grid Architecture Committee (2009) IEEE P 2030 (2010) IEC Smart Grid Other


Architecture Puts a Technical Frameworkaround Key Relationships RegulatorsStandardsand User GroupCommunitiesGovernmentAgenciesProduct VendorsIndustry Projectsand R&DUtilities andEnergy CompaniesEnergy Consumers

CONTACT INFORMATIONJoe Hughes, Reef Energy Systems, LLCreefarch@gmail.com925 786 2775SGIP SGAC n/view/SmartGrid/SmartGridArchitectureCommittee

distributed computing "environments" Information Systems "Soft" Real-time "Hard" Real-time Delays are tolerable Short delays are Delays can fail an application, delays must be predictable "deterministic" E-mail, Internet Document Distribution Database access over a LAN Automated Control Functions Examples Application Delay

Related Documents:

Smart Grid and Cyber-Physical Systems Office National Institute of Standards and Technology U.S. Department of Commerce Smart Grid And CPS Testbed Update Smart Grid Federal Advisory Committee Meeting June 3, 2014. 2. Smart Grid and Cyber ‐ Physical Systems Testbeds Layout. Smart Microgrid Control Smart andRoom Intelligent Device Smart Storage .

emissions reduction from smart grid deployment 28 14. Smart grid product providers 33 List of Tables 1. Characteristics of smart grids 7 2. Workshop contributions to the Smart Grids Roadmap 8 3. Smart grid technologies 19 4. Maturity levels and development trends of smart grid technologies 20 5. Select national smart grid deployment efforts 21 6.

Therefore, DSM in smart grid is more extensive than the traditional power grid. 1) To achieve a good interaction between the grid and the user The main characteristics and the goal of building the smart grid is to realize the "intelligent interactive",DSM in Smart Grid is no longer a simple power management, the power grid enterprises

1 Review of Public Private Partnerships (PPPs) in Smart Grid Investments 1 1.1 Context 1 1.1.1 When is a grid smart? 1 1.1.2 Functional categories of smart grids 2 1.1.3 What is a PPP? 5 1.1.4 Opportunities for using PPPs in smart grid development 5 1.2 Recent Trends in Smart Grid Projects 6 1.2.1 Enhancing transmission and distribution grid

Defining the Pathway to the California Smart Grid of 2020 PIER Funded RD&D Activities: Micro-Grid demonstrations of Smart Grid technologies White Paper on defining the Smart Grid standards, codes and protocols White Paper on the Smart Grid technologies that will accelerate the

problematic grid component. The smart grid will bring new features into the power grid such as renewable-based generation, demand-response, wide area protection, smart metering, etc. The core of the smart grid is an intelligent communication system that links all compo-nents together in an efficient and secure manner. Smart grid

Interfaces of the Smart Grid includes an overall functional logical architecture of the Smart Grid - including all the major domains . This architecture focuses on a short-term view (1-3 years)of the proposed Smart Grid. The chapter also includes individual logical interface diagrams for six areas : electric transportation, electric

smart grids for smart cities Strategic Options for Smart Grid Communication Networks To meet the goals of a smart city in supporting a sustainable high-quality lifestyle for citizens, a smart city needs a smart grid. To build smart cities of the future, Information and Communications Techn