ddsf:public:guidebook:03_user:03_tms
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ddsf:public:guidebook:03_user:03_tms [2021/07/14 15:44] murphy ↷ Links adapted because of a move operation |
ddsf:public:guidebook:03_user:03_tms [2021/09/02 19:43] (current) mitza [Table] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Use Case 2: Tactical Microgrid Standard (TMS) ====== | ====== Use Case 2: Tactical Microgrid Standard (TMS) ====== | ||
| [[ddsf:public:guidebook:03_user:start| Return to User Experiences]] | [[ddsf:public:guidebook:03_user:start| Return to User Experiences]] | ||
| - | |||
| - | * **<color #FF0000><todo @char>Please Review</todo></color>** | ||
| - | * **<color #FF0000><todo @DDSFmember>Please Review</todo></color>** | ||
| - | |||
| ===== Details ===== | ===== Details ===== | ||
| - | ^ Author | Daniel Herring | | + | ^ Author | Daniel Herring | |
| - | ^ Title | Associate Staff | | + | ^ Title | Associate Staff | |
| - | ^ Organization | MIT Lincoln Laboratory | | + | ^ Organization | MIT Lincoln Laboratory | |
| - | ^ Date | 28 May 2020 | | + | ^ Date | 28 May 2020 | |
| - | ^ Time | 31 Minutes | | + | ^ Time | 31 Minutes | |
| - | ^ Presentation | [[https://www.brighttalk.com/webcast/12231/401676?utm_campaign=channel-feed&utm_source=brighttalk-portal&utm_medium=web | Pactical Microgrid Standard - DDSF BrightTalk ]] | | + | ^ Presentation | [[https://www.brighttalk.com/webcast/12231/401676?utm_campaign=channel-feed&utm_source=brighttalk-portal&utm_medium=web| Tactical Microgrid Standard - DDSF BrightTalk ]] | |
| - | ^ Document | [[http://public2.brighttalk.com/resource/core/274119/dds-foundation_tms-use-case-20200527_609918.pdf | Pactical Microgrid Standard ]] | | + | ^ Document | [[http://public2.brighttalk.com/resource/core/274119/dds-foundation_tms-use-case-20200527_609918.pdf| Tactical Microgrid Standard ]] | |
| ===== Tactical Microgrid Standard (TMS) Using DDS for Secure Communications ===== | ===== Tactical Microgrid Standard (TMS) Using DDS for Secure Communications ===== | ||
| Line 20: | Line 16: | ||
| ===== Abstract ===== | ===== Abstract ===== | ||
| - | A proposed Tactical [[ddsf:private:guidebook:06_append:glossary:m:microgrid]] Standard (TMS) is a new [[ddsf:public:guidebook:06_append:glossary:e:egrid|power grid]] system architecture, developed to meet [[ddsf:public:guidebook:06_append:glossary:d:dod]] and industry needs. TMS offers unique features that address challenges faced by existing power systems. [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] provides resilient and secure publish/subscribe communications for TMS. The presenter, Daniel Herring has used DDS for 14 years at MIT Lincoln Laboratory and shares some experience on what DDS enables and how DDS can be introduced to other organizations. | + | A proposed Tactical [[ddsf:public:guidebook:06_append:glossary:m:microgrid]] Standard (TMS) is a new [[ddsf:public:guidebook:06_append:glossary:e:egrid|power grid]] system architecture, developed to meet [[ddsf:public:guidebook:06_append:glossary:d:dod]] and industry needs. TMS offers unique features that address challenges faced by existing power systems. [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] provides resilient and secure publish/subscribe communications for TMS. The presenter, Daniel Herring has used DDS for 14 years at MIT Lincoln Laboratory and shares some experience on what DDS enables and how DDS can be introduced to other organizations. |
| ==== Attribution ==== | ==== Attribution ==== | ||
| Line 42: | Line 38: | ||
| * Better integration of components to provide system-level behaviors | * Better integration of components to provide system-level behaviors | ||
| - | TMS applies the following design principles to [[ddsf:private:guidebook:06_append:glossary:s:sgrid]] applications: | + | TMS applies the following design principles to [[ddsf:public:guidebook:06_append:glossary:s:sgrid]] applications: |
| * Simple -- require less expertise, planning, and time | * Simple -- require less expertise, planning, and time | ||
| Line 50: | Line 46: | ||
| * Scalable -- grow in size over time | * Scalable -- grow in size over time | ||
| * Extensible -- grow in features over time | * Extensible -- grow in features over time | ||
| - | * [[ddsf:private:guidebook:06_append:glossary:o:oa]] -- support a wide range of manufacturers and product lines | + | * [[ddsf:public:guidebook:06_append:glossary:o:oa]] -- support a wide range of manufacturers and product lines |
| <figure SysArch> | <figure SysArch> | ||
| Line 58: | Line 54: | ||
| - | Since the advent of the [[ddsf:public:guidebook:06_append:glossary:e:egrid]], our society's dependence on electricity has grown and it is now an essential utility. For example, electricity powers the [[ddsf:private:guidebook:06_append:glossary:i:internet|internet]] technologies that are so essential to modern society. A rare power outage lasting a second, minute, hour, or day may be tolerable. Frequent outages or ones lasting a week, month, or year would cause significant social and economic harm. Some recent, high profile instances of power losses due to natural disasters are hurricanes, earthquakes and fires (i.e., New Orleans, Puerto Rico(( | + | Since the advent of the [[ddsf:public:guidebook:06_append:glossary:e:egrid]], our society's dependence on electricity has grown and it is now an essential utility. For example, electricity powers the [[ddsf:public:guidebook:06_append:glossary:i:internet|internet]] technologies that are so essential to modern society. A rare power outage lasting a second, minute, hour, or day may be tolerable. Frequent outages or ones lasting a week, month, or year would cause significant social and economic harm. Some recent, high profile instances of power losses due to natural disasters are hurricanes, earthquakes and fires (i.e., New Orleans, Puerto Rico(( |
| Puerto Rico Power Fully Restored 18 Months After Hurricane Maria Wiped Out the Grid, Weather Channel News, 21 March 2019 | Puerto Rico Power Fully Restored 18 Months After Hurricane Maria Wiped Out the Grid, Weather Channel News, 21 March 2019 | ||
| )) and California(( | )) and California(( | ||
| Line 72: | Line 68: | ||
| Furthermore, there is a need for better ways of integrating power systems. We want to accelerate the release of new technologies, reduce costs, and increase automation between devices, all at the same time. | Furthermore, there is a need for better ways of integrating power systems. We want to accelerate the release of new technologies, reduce costs, and increase automation between devices, all at the same time. | ||
| - | As a consequence, this has driven for a lot of new [[ddsf:private:guidebook:06_append:glossary:r:requirement|requirements]] for utility infrastructure. There are hundreds to thousands of companies working in the energy sector and they need a common platform to facilitate integration of their solutions. TMS meets this need for a wide range of on-site power use cases. | + | As a consequence, this has driven for a lot of new [[ddsf:public:guidebook:06_append:glossary:r:requirement|requirements]] for utility infrastructure. There are hundreds to thousands of companies working in the energy sector and they need a common platform to facilitate integration of their solutions. TMS meets this need for a wide range of on-site power use cases. |
| Line 82: | Line 78: | ||
| Grid Components: | Grid Components: | ||
| - | * **Power Sources** are large generators of electricity that use traditional energy resources such as as coal, oil, natural gas and nuclear as well as [[ddsf:private:guidebook:06_append:glossary:r:renewerg|reneable resources]] such as solar and wind (not listed in graphic). | + | * **Power Sources** are large generators of electricity that use traditional energy resources such as as coal, oil, natural gas and nuclear as well as [[ddsf:public:guidebook:06_append:glossary:r:renewerg|reneable resources]] such as solar and wind (not listed in graphic). |
| * **Power Transmission** is the network of high voltage lines (cables) that connect sources to electric substations, where it is dropped to medium voltage. | * **Power Transmission** is the network of high voltage lines (cables) that connect sources to electric substations, where it is dropped to medium voltage. | ||
| * ** Heavy Industry ** includes high-power consumers such as furnaces, electrolysis, and smelting ((Siemens, High-current industrial transformers, Acessed: 12 Jun2020, [[https://new.siemens.com/global/en/products/energy/high-voltage/transformers/high-current-industrial-transformers.html]])) | * ** Heavy Industry ** includes high-power consumers such as furnaces, electrolysis, and smelting ((Siemens, High-current industrial transformers, Acessed: 12 Jun2020, [[https://new.siemens.com/global/en/products/energy/high-voltage/transformers/high-current-industrial-transformers.html]])) | ||
| * ** Power Distribution** is the network of medium voltage lines that connect electric substations to most consumers. | * ** Power Distribution** is the network of medium voltage lines that connect electric substations to most consumers. | ||
| * ** Consumers ** are the normal light industry loads and residential neighborhoods. | * ** Consumers ** are the normal light industry loads and residential neighborhoods. | ||
| - | * ** [[ddsf:private:guidebook:06_append:glossary:o:offgrid]] ** applications have on-site power generation capabilities and may not be connected directly to utility power. They are self contained. This isolation can be due to remote operating location or by design to protect mission critical services from attacks through the utility. | + | * ** [[ddsf:public:guidebook:06_append:glossary:o:offgrid]] ** applications have on-site power generation capabilities and may not be connected directly to utility power. They are self contained. This isolation can be due to remote operating location or by design to protect mission critical services from attacks through the utility. |
| In addition, there are some cross grid component functions: | In addition, there are some cross grid component functions: | ||
| - | * **Supervisory Control Plain** that coordinates the Power Sources, Transmission and Sinks. The Control is an integrated set of [[ddsf:private:guidebook:06_append:glossary:s:scada]] applications along with human operators sitting in control rooms making decisions while in contact with other operators usually over phones. | + | * **Supervisory Control Plain** that coordinates the Power Sources, Transmission and Sinks. The Control is an integrated set of [[ddsf:public:guidebook:06_append:glossary:s:scada]] applications along with human operators sitting in control rooms making decisions while in contact with other operators usually over phones. |
| - | * **Disaster Response** needs to span the whole system from the **Power Sources** to the **Sinks**. Some examples of disasters that require coordinated responses from [[ddsf:public:guidebook:06_append:glossary:f:fema]], [[ddsf:private:guidebook:06_append:glossary:u:usace]], or some other agency are hurricanes, tornadoes, dam breaches, earthquakes, bridge failures, etc. Closely related to Disaster Response are humanity assistance missions in other regions of the world. Within the US, the Joint Chiefs of Staff, Foreign Humanitarian Assistance covers these situations. ((Foreign Humanitarian Assistance, Joint Publication 3-29, 14 May 2019, [[https://www.jcs.mil/Portals/36/Documents/Doctrine/pubs/jp3_29.pdf]] | + | * **Disaster Response** needs to span the whole system from the **Power Sources** to the **Sinks**. Some examples of disasters that require coordinated responses from [[ddsf:public:guidebook:06_append:glossary:f:fema]], [[ddsf:public:guidebook:06_append:glossary:u:usace]], or some other agency are hurricanes, tornadoes, dam breaches, earthquakes, bridge failures, etc. Closely related to Disaster Response are humanity assistance missions in other regions of the world. Within the US, the Joint Chiefs of Staff, Foreign Humanitarian Assistance covers these situations. ((Foreign Humanitarian Assistance, Joint Publication 3-29, 14 May 2019, [[https://www.jcs.mil/Portals/36/Documents/Doctrine/pubs/jp3_29.pdf]] |
| )) | )) | ||
| * **Critical Infrastructure Operations** in the US, refers operations conducted at specifically designated [[ddsf:public:guidebook:06_append:glossary:c:critinfra]] whose assets and networks are vital to the US security. Some examples are military bases, a hospitals, or some other community center that needs special hardening, so if there is a disaster or failure on the grid at large, that location can continue to operate undisturbed.(( | * **Critical Infrastructure Operations** in the US, refers operations conducted at specifically designated [[ddsf:public:guidebook:06_append:glossary:c:critinfra]] whose assets and networks are vital to the US security. Some examples are military bases, a hospitals, or some other community center that needs special hardening, so if there is a disaster or failure on the grid at large, that location can continue to operate undisturbed.(( | ||
| Line 106: | Line 102: | ||
| - | The Tactical Microgrid Standard (TMS) is primarily developed for tactical systems that are categorized as forward deployments. These **Forward Deployment Operations** are the focus this [[ddsf:private:guidebook:06_append:glossary:u:use_case|Use Case]] study. However, the benefits of the TMS are not restricted to tactical [[ddsf:private:guidebook:06_append:glossary:o:offgrid| off-grid]] operations and the adoption and adaption of the TMS to non-tactical situations is encouraged. TMS has many technological similarities to the other application scenarios. In fact some of the first implementation of the TMS are in the area of **Critical Infrastructure Operations** describe above. | + | The Tactical Microgrid Standard (TMS) is primarily developed for tactical systems that are categorized as forward deployments. These **Forward Deployment Operations** are the focus this [[ddsf:public:guidebook:06_append:glossary:u:use_case|Use Case]] study. However, the benefits of the TMS are not restricted to tactical [[ddsf:public:guidebook:06_append:glossary:o:offgrid| off-grid]] operations and the adoption and adaption of the TMS to non-tactical situations is encouraged. TMS has many technological similarities to the other application scenarios. In fact some of the first implementation of the TMS are in the area of **Critical Infrastructure Operations** describe above. |
| <figure> | <figure> | ||
| Line 117: | Line 113: | ||
| [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | ||
| - | A bit more background on the [[ddsf:private:guidebook:06_append:glossary:o:offgrid]] Use Case. Figure {{ref>OpsOverview}} represents an example of a [[ddsf:private:guidebook:06_append:glossary:m:microgrid]] at a **Forward Operating Base**. In this example, there a few dozen tents on a site with potentially hundreds to thousands of people engaged in the operations. This single base site is power by multiple generation sources, has its own power distribution network and has diverse and physically distributed loads. The base is war fighter owned and operated and is self-sufficient and self-contained. It is important to note that each Forward Operating Site has a unique situation including its specific mission, [[ddsf:private:guidebook:06_append:glossary:g:goal|goals]], needs and geographic location. However, the sites share a lot of similarities in terms of power generation, transmission and load. (i.e., they are all [[ddsf:private:guidebook:06_append:glossary:m:microgrid| Microgrids]]). Some common loads include **Communications**, **Sensors**, **Weapons** and least interesting but actually the post power goes to **Climate Control** (i.e., bases in extreme climate conditions require keeping people comfortable and equipment operating within the allowable environmental specifications.) | + | A bit more background on the [[ddsf:public:guidebook:06_append:glossary:o:offgrid]] Use Case. Figure {{ref>OpsOverview}} represents an example of a [[ddsf:public:guidebook:06_append:glossary:m:microgrid]] at a **Forward Operating Base**. In this example, there a few dozen tents on a site with potentially hundreds to thousands of people engaged in the operations. This single base site is power by multiple generation sources, has its own power distribution network and has diverse and physically distributed loads. The base is war fighter owned and operated and is self-sufficient and self-contained. It is important to note that each Forward Operating Site has a unique situation including its specific mission, [[ddsf:public:guidebook:06_append:glossary:g:goal|goals]], needs and geographic location. However, the sites share a lot of similarities in terms of power generation, transmission and load. (i.e., they are all [[ddsf:public:guidebook:06_append:glossary:m:microgrid| Microgrids]]). Some common loads include **Communications**, **Sensors**, **Weapons** and least interesting but actually the post power goes to **Climate Control** (i.e., bases in extreme climate conditions require keeping people comfortable and equipment operating within the allowable environmental specifications.) |
| <figure OpsOverview> | <figure OpsOverview> | ||
| Line 159: | Line 155: | ||
| There were four existing Microgrid architectures evaluated for developing the new TMS. These architectures are represented in Figure {{ref>BeforTms}}. The following is a discussion of the four architectures: | There were four existing Microgrid architectures evaluated for developing the new TMS. These architectures are represented in Figure {{ref>BeforTms}}. The following is a discussion of the four architectures: | ||
| - | * **[[ddsf:private:guidebook:06_append:glossary:s:spot]]** - is very simple architecture and the [[ddsf:public:guidebook:06_append:glossary:d:dod| DoD]] started using it around World War II (WWII) and purchased a lot of inventory during the Vietnam War. This is a typical approach today. Its simple to setup. When a tent needs power, simply setup a generator outside and run a cable into the tent. The **Spot Generation** is also is very inefficient because it uses a lot more generators than are needed. Often the generators tend to idle a much of the time resulting wasted fuel. The **Spot Generation** architectures are fairly fragile since when a generator fails, the power in the tent go out resulting in the loss of mission functionality for that tent. | + | * **[[ddsf:public:guidebook:06_append:glossary:s:spot]]** - is very simple architecture and the [[ddsf:public:guidebook:06_append:glossary:d:dod| DoD]] started using it around World War II (WWII) and purchased a lot of inventory during the Vietnam War. This is a typical approach today. Its simple to setup. When a tent needs power, simply setup a generator outside and run a cable into the tent. The **Spot Generation** is also is very inefficient because it uses a lot more generators than are needed. Often the generators tend to idle a much of the time resulting wasted fuel. The **Spot Generation** architectures are fairly fragile since when a generator fails, the power in the tent go out resulting in the loss of mission functionality for that tent. |
| * **[[ddsf:public:guidebook:06_append:glossary:c:consgen]]** attempts to improve on the inefficiency of **Spot generation**, by running distribution cables to multiple tents. it does improve efficiency by better matching the load to the source, however, this kind of optimization ends up being more complicated and adding more mission functionality losses if a generator fails. As a result, it is not widely used.__**<todo @daniel>I want to add the term officially here because I'm sure that the creative field engineers will do this if one generator fails and just "tap into" another generator</todo>**__ | * **[[ddsf:public:guidebook:06_append:glossary:c:consgen]]** attempts to improve on the inefficiency of **Spot generation**, by running distribution cables to multiple tents. it does improve efficiency by better matching the load to the source, however, this kind of optimization ends up being more complicated and adding more mission functionality losses if a generator fails. As a result, it is not widely used.__**<todo @daniel>I want to add the term officially here because I'm sure that the creative field engineers will do this if one generator fails and just "tap into" another generator</todo>**__ | ||
| Line 165: | Line 161: | ||
| * **[[ddsf:public:guidebook:06_append:glossary:c:cntrgrid]]** locates all the generators in one location and then fans out all the power through a **Transmission Network** to all the tents that require power. The **Central Microgrid** combines the positive characteristics of the **Spot** and **Consolidated Generation** into a single architecture by providing some backup generation capabilities. For example, extra generator(s) can be located on the site providing redundancy to protect against generator fails by balancing the power production to the extra generator(s). Unfortunately, there is even more dependent on cables om the **Transmission Network**. Another drawback is that **Central Microgrids** available in the market place today require one vendor for all generators at a site meaning that you can not mix and match across generators from different companies or even within product lines from single company due to issues in communication control as well as other aspects of how the system function. There are some actual deployments available in the marketplace today, the [[https://asc.army.mil/web/portfolio-item/cs-css-advanced-medium-mobile-power-source-ammps/ | Advanced Medium Mobile Power System (AMMPS)]] Microgrid is being deployed in the DoD inventory with a 2019 purchase another $0.5B worth of available equipment. | * **[[ddsf:public:guidebook:06_append:glossary:c:cntrgrid]]** locates all the generators in one location and then fans out all the power through a **Transmission Network** to all the tents that require power. The **Central Microgrid** combines the positive characteristics of the **Spot** and **Consolidated Generation** into a single architecture by providing some backup generation capabilities. For example, extra generator(s) can be located on the site providing redundancy to protect against generator fails by balancing the power production to the extra generator(s). Unfortunately, there is even more dependent on cables om the **Transmission Network**. Another drawback is that **Central Microgrids** available in the market place today require one vendor for all generators at a site meaning that you can not mix and match across generators from different companies or even within product lines from single company due to issues in communication control as well as other aspects of how the system function. There are some actual deployments available in the marketplace today, the [[https://asc.army.mil/web/portfolio-item/cs-css-advanced-medium-mobile-power-source-ammps/ | Advanced Medium Mobile Power System (AMMPS)]] Microgrid is being deployed in the DoD inventory with a 2019 purchase another $0.5B worth of available equipment. | ||
| - | * **[[ddsf:public:guidebook:06_append:glossary:d:distgrid]]** is attractive because it has the efficiency of the **Central Microgrid** but also has redundant **Transmission Network** cabling. In a **Distributed Microgrid** each generator's load is independently adjustable resulting in a more complicated control problem. Consequently, __with existing technologies__, it is more complicated to setup and has more proprietary [[ddsf:private:guidebook:06_append:glossary:v:vendorlockin|vendor lock-in]]. **Note:** in a **Central Microgrid**, all the generators must support an equal fraction of the load. | + | * **[[ddsf:public:guidebook:06_append:glossary:d:distgrid]]** is attractive because it has the efficiency of the **Central Microgrid** but also has redundant **Transmission Network** cabling. In a **Distributed Microgrid** each generator's load is independently adjustable resulting in a more complicated control problem. Consequently, __with existing technologies__, it is more complicated to setup and has more proprietary [[ddsf:public:guidebook:06_append:glossary:v:vendorlockin|vendor lock-in]]. **Note:** in a **Central Microgrid**, all the generators must support an equal fraction of the load. |
| In summary, Figure {{ref>BeforTms}} graphicaly represents the Tactical Microgrid landscape before TMS. | In summary, Figure {{ref>BeforTms}} graphicaly represents the Tactical Microgrid landscape before TMS. | ||
| Line 182: | Line 178: | ||
| With TMS, many of the previous issues become solutions | With TMS, many of the previous issues become solutions | ||
| - | * TMS, by definition is an [[ddsf:private:guidebook:06_append:glossary:o:oa]], so it directly tackles many of the proprietary vendor lock-in issues | + | * TMS, by definition is an [[ddsf:public:guidebook:06_append:glossary:o:oa]], so it directly tackles many of the proprietary vendor lock-in issues |
| * Anecdotal [[ddsf:public:guidebook:06_append:glossary:e:evidence|evidence]] suggests that TMS changes to how the system is operated and maintained make the **Distributed Microgrid** architecture as simple to setup and operated as the other architectures (i.e., **Spot Generation**, **Consolidated Generation** and **Central Microgrid**. | * Anecdotal [[ddsf:public:guidebook:06_append:glossary:e:evidence|evidence]] suggests that TMS changes to how the system is operated and maintained make the **Distributed Microgrid** architecture as simple to setup and operated as the other architectures (i.e., **Spot Generation**, **Consolidated Generation** and **Central Microgrid**. | ||
| Line 232: | Line 228: | ||
| - | Figure {{ref>TmsComp}} shows the Components and Interfaces defined within the TMS Architecture. Inside each component, unit or device, there are also a few interfaces defined at the software and hardware levels providing some [[ddsf:private:guidebook:06_append:glossary:m:modularity|modularity]]. | + | Figure {{ref>TmsComp}} shows the Components and Interfaces defined within the TMS Architecture. Inside each component, unit or device, there are also a few interfaces defined at the software and hardware levels providing some [[ddsf:public:guidebook:06_append:glossary:m:modularity|modularity]]. |
| Each component has a number of external interlaces to the other components within a TMS system. The major system Interfaces are: | Each component has a number of external interlaces to the other components within a TMS system. The major system Interfaces are: | ||
| Line 244: | Line 240: | ||
| * **Power Hardware** may have a life expectancy of 30+ years, however, the the computing technology can be refreshed more frequently. | * **Power Hardware** may have a life expectancy of 30+ years, however, the the computing technology can be refreshed more frequently. | ||
| - | * **Control Hardware** a key aspect of the TMS Architecture is the **[[ddsf:public:guidebook:06_append:glossary:d:dm]]**. The **Data Model** describes the messages flowing back and forth, what the end points are, what the contents of the messages are, and what triggers the messages to go back and forth. Part of the **Data Model** are [[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:interface_definitions_language_idl| Interface Definition Language (IDL)]], [[ddsf:private:guidebook:06_append:glossary:q:quality_of_service_qos_policies| Quality of Service (QoS)]], [[ddsf:private:guidebook:06_append:glossary:t:topic| Topics]], the other things related to DDS. | + | * **Control Hardware** a key aspect of the TMS Architecture is the **[[ddsf:public:guidebook:06_append:glossary:d:dm]]**. The **Data Model** describes the messages flowing back and forth, what the end points are, what the contents of the messages are, and what triggers the messages to go back and forth. Part of the **Data Model** are [[ddsf:public:guidebook:06_append:01_family_of_standards:01_core:interface_definitions_language_idl| Interface Definition Language (IDL)]], [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies| Quality of Service (QoS)]], [[ddsf:public:guidebook:06_append:glossary:t:topic| Topics]], the other things related to DDS. |
| * **Cybersecurity** maps the physical identity of the hardware to the cryptographic identity stored in hardware modules. It also provides software allowing for the [[ddsf:public:guidebook:06_append:glossary:e:end-to-end_e2e|end-to-end]] trust. For example, being able to trust a power measurement coming from a known device, and is the data actually shown on the display matching and reflecting what is happening in the field. Another example would trusting the commands sent to devices are coming from authorized users and authorized Microgrid controllers. | * **Cybersecurity** maps the physical identity of the hardware to the cryptographic identity stored in hardware modules. It also provides software allowing for the [[ddsf:public:guidebook:06_append:glossary:e:end-to-end_e2e|end-to-end]] trust. For example, being able to trust a power measurement coming from a known device, and is the data actually shown on the display matching and reflecting what is happening in the field. Another example would trusting the commands sent to devices are coming from authorized users and authorized Microgrid controllers. | ||
| Line 304: | Line 300: | ||
| [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | ||
| - | [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] is a key part in the success story for TMS. It is a key enabling technology and is the communications [[ddsf:private:guidebook:06_append:glossary:m:midware]] that helps create tie the components together. It also has an immediate benefit of creating modularity between components during integration. The proposed standard requires the use of DDS for defining publish and subscribe topics, the [[ddsf:public:guidebook:06_append:glossary:d:datatype]] (i.e., structures) used in the topic and the [[ddsf:private:guidebook:06_append:glossary:q:quality_of_service_qos_policies]]. This requirement increases the confidence that all implementations will be compatible with the expected behaviors. | + | [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] is a key part in the success story for TMS. It is a key enabling technology and is the communications [[ddsf:public:guidebook:06_append:glossary:m:midware]] that helps create tie the components together. It also has an immediate benefit of creating modularity between components during integration. The proposed standard requires the use of DDS for defining publish and subscribe topics, the [[ddsf:public:guidebook:06_append:glossary:d:datatype]] (i.e., structures) used in the topic and the [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies]]. This requirement increases the confidence that all implementations will be compatible with the expected behaviors. |
| There were many other technologies middleware infrastructures considered for use in TMS. DDS stood out in several areas: | There were many other technologies middleware infrastructures considered for use in TMS. DDS stood out in several areas: | ||
| Line 313: | Line 309: | ||
| * Strong Technology | * Strong Technology | ||
| * Fully distributed publish/subscribe (pub/sub) and there is no central point of failure | * Fully distributed publish/subscribe (pub/sub) and there is no central point of failure | ||
| - | * Machine-readable [[ddsf:private:guidebook:06_append:glossary:i:idl]] | + | * Machine-readable [[ddsf:public:guidebook:06_append:glossary:i:idl]] |
| * Rich Quality of Service (QoS) allows for the tune it to support many different data flows. | * Rich Quality of Service (QoS) allows for the tune it to support many different data flows. | ||
| * Portable [[ddsf:public:guidebook:06_append:glossary:a:api]] | * Portable [[ddsf:public:guidebook:06_append:glossary:a:api]] | ||
| - | * Interoperable [[ddsf:private:guidebook:06_append:glossary:w:wireprotocol|wire protocol]] | + | * Interoperable [[ddsf:public:guidebook:06_append:glossary:w:wireprotocol|wire protocol]] |
| * Security architecture provided a near term capability and an upgrade roadmap | * Security architecture provided a near term capability and an upgrade roadmap | ||
| - | * Healthy Ecosystem through the stable governance provided by [[ddsf:private:guidebook:06_append:glossary:o:omg]] and the various DDS vendors are working together to keep this as an Open Standard that improves over time. | + | * Healthy Ecosystem through the stable governance provided by [[ddsf:public:guidebook:06_append:glossary:o:omg]] and the various DDS vendors are working together to keep this as an Open Standard that improves over time. |
| - | * Open standard developed by an [[ddsf:private:guidebook:06_append:glossary:s:stdorg]] | + | * Open standard developed by an [[ddsf:public:guidebook:06_append:glossary:s:stdorg]] |
| * Stable open, transparent governance | * Stable open, transparent governance | ||
| * Multiple independent commercial implementations | * Multiple independent commercial implementations | ||
| Line 339: | Line 335: | ||
| **TMS** provides **Architecture** artifacts: | **TMS** provides **Architecture** artifacts: | ||
| - | * **[[ddsf:private:guidebook:06_append:glossary:p:pdf]]** providing some human readable documentation about TMS: what things are; and how things work | + | * **[[ddsf:public:guidebook:06_append:glossary:p:pdf]]** providing some human readable documentation about TMS: what things are; and how things work |
| - | * **[[ddsf:private:guidebook:06_append:glossary:i:idl]]** providing machine readable information about the [[ddsf:private:guidebook:06_append:glossary:t:topic]], [[ddsf:public:guidebook:06_append:glossary:d:datatype| datatypes]] | + | * **[[ddsf:public:guidebook:06_append:glossary:i:idl]]** providing machine readable information about the [[ddsf:public:guidebook:06_append:glossary:t:topic]], [[ddsf:public:guidebook:06_append:glossary:d:datatype| datatypes]] |
| - | * **[[ddsf:private:guidebook:06_append:glossary:x:xml]]** providing machine readable information about QoS and system configuration. | + | * **[[ddsf:public:guidebook:06_append:glossary:x:xml]]** providing machine readable information about QoS and system configuration. |
| **OMG** provides **DDS** and related products artifacts: | **OMG** provides **DDS** and related products artifacts: | ||
| - | * **[[ddsf:private:guidebook:06_append:glossary:p:pdf]]** providing some human readable documentation about DDS and related tools: what things are; and how things work | + | * **[[ddsf:public:guidebook:06_append:glossary:p:pdf]]** providing some human readable documentation about DDS and related tools: what things are; and how things work |
| - | * **[[ddsf:private:guidebook:06_append:glossary:i:idl]]** preprocessor and other tools providing machine readable information used to autogenerate type support, topics and other things used in your application | + | * **[[ddsf:public:guidebook:06_append:glossary:i:idl]]** preprocessor and other tools providing machine readable information used to autogenerate type support, topics and other things used in your application |
| - | * **[[ddsf:private:guidebook:06_append:glossary:s:swlib]]** runtime library for the DDS products | + | * **[[ddsf:public:guidebook:06_append:glossary:s:swlib]]** runtime library for the DDS products |
| **Application** provides the software focusing on the particular aspects of the Microgrid rather than the infrastructure required to run that software. | **Application** provides the software focusing on the particular aspects of the Microgrid rather than the infrastructure required to run that software. | ||
| - | * **Application Sources** is [[ddsf:private:guidebook:06_append:glossary:s:sourcecode]] written to solve a specific problem within the TMS Domain. | + | * **Application Sources** is [[ddsf:public:guidebook:06_append:glossary:s:sourcecode]] written to solve a specific problem within the TMS Domain. |
| - | * **[[ddsf:public:guidebook:06_append:glossary:c:compiler| Compiler(s)]]** used to convert the [[ddsf:private:guidebook:06_append:glossary:s:sourcecode]] to an Executable. | + | * **[[ddsf:public:guidebook:06_append:glossary:c:compiler| Compiler(s)]]** used to convert the [[ddsf:public:guidebook:06_append:glossary:s:sourcecode]] to an Executable. |
| * **[[ddsf:public:guidebook:06_append:glossary:e:exec| Executable]]** is the application code to be deployed on the **Components**, **Devices** on the Microgrid. | * **[[ddsf:public:guidebook:06_append:glossary:e:exec| Executable]]** is the application code to be deployed on the **Components**, **Devices** on the Microgrid. | ||
| Line 364: | Line 360: | ||
| [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | [[ddsf:public:guidebook:03_user:03_tms| Return to the top]] | ||
| - | Figure {{ref>Summary}} provides a list of Challenges and Takeaways during the adoption of [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:private:guidebook:06_append:glossary:m:midware]] within TMS. So far, it has been a success story. Most of the partners that we have worked with are new to DDS. The faced a number of challenges, as they get started. At first there are questions about how much hardware is needed and what constraints does DDS place on their software? | + | Figure {{ref>Summary}} provides a list of Challenges and Takeaways during the adoption of [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:public:guidebook:06_append:glossary:m:midware]] within TMS. So far, it has been a success story. Most of the partners that we have worked with are new to DDS. The faced a number of challenges, as they get started. At first there are questions about how much hardware is needed and what constraints does DDS place on their software? |
| ==== Challenges ==== | ==== Challenges ==== | ||
| Line 370: | Line 366: | ||
| * Planning requirements | * Planning requirements | ||
| - | * Hardware: [[ddsf:public:guidebook:06_append:glossary:c:cpu|CPU]], memory, and network - [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:private:guidebook:06_append:glossary:m:midware]] does requires some more hardware | + | * Hardware: [[ddsf:public:guidebook:06_append:glossary:c:cpu|CPU]], memory, and network - [[ddsf:public:guidebook:06_append:glossary:d:data_distribution_service_dds]] [[ddsf:public:guidebook:06_append:glossary:m:midware]] does requires some more hardware |
| - | * Software: language, [[ddsf:private:guidebook:06_append:glossary:o:os]], standard [[ddsf:private:guidebook:06_append:glossary:m:midware]] is more sophisticated than [[ddsf:private:guidebook:06_append:glossary:p:protocol| protocols]] that were developed during the 90's. However, for a modern system is fairly lightweight and efficient, so there has not been much resistance there. | + | * Software: language, [[ddsf:public:guidebook:06_append:glossary:o:os]], standard [[ddsf:public:guidebook:06_append:glossary:m:midware]] is more sophisticated than [[ddsf:public:guidebook:06_append:glossary:p:protocol| protocols]] that were developed during the 90's. However, for a modern system is fairly lightweight and efficient, so there has not been much resistance there. |
| * Getting started - There were many questions about how to get started | * Getting started - There were many questions about how to get started | ||
| Line 381: | Line 377: | ||
| * Samples, keys, filters, buffers | * Samples, keys, filters, buffers | ||
| * Event handling | * Event handling | ||
| - | * [[ddsf:private:guidebook:06_append:glossary:t:topic| Topics]], [[ddsf:private:guidebook:06_append:glossary:i:idl]], and [[ddsf:private:guidebook:06_append:glossary:q:quality_of_service_qos_policies]] | + | * [[ddsf:public:guidebook:06_append:glossary:t:topic| Topics]], [[ddsf:public:guidebook:06_append:glossary:i:idl]], and [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies]] |
| * Debug and testing tools - We have been working with the OMG and the DDS Foundation to improve the debug and testing tools and documentation about the optional parts of the standard | * Debug and testing tools - We have been working with the OMG and the DDS Foundation to improve the debug and testing tools and documentation about the optional parts of the standard | ||
| Line 397: | Line 393: | ||
| * TMS provides domain-specific | * TMS provides domain-specific | ||
| * Documentation, FAQ | * Documentation, FAQ | ||
| - | * [[ddsf:private:guidebook:06_append:glossary:t:topic| Topics]], [[ddsf:private:guidebook:06_append:glossary:i:idl]], and [[ddsf:private:guidebook:06_append:glossary:q:quality_of_service_qos_policies]] | + | * [[ddsf:public:guidebook:06_append:glossary:t:topic| Topics]], [[ddsf:public:guidebook:06_append:glossary:i:idl]], and [[ddsf:public:guidebook:06_append:glossary:q:quality_of_service_qos_policies]] |
| * Tools | * Tools | ||
ddsf/public/guidebook/03_user/03_tms.1626291890.txt.gz · Last modified: 2021/07/14 15:44 by murphy
