SLC: Technology to SLC connections

SLC: Technology to SLC connections

I thought I had this in part of another issue but I can't find it. Some future system-level controller may require additional information about a technology that is not by default connected in the H2I framework. For inputs to the SLC models, both the SLC and H2I need to know what this input is (so the SLC can make it an input and H2I can connect it). Since some on-going work in SLC methods leverages the technology_interconnections so heavily - I think that the control-specific or user-input connections from technologies to SLC models should be in a separate connections list that is not technology_interconnections. I propose that, for example, it'd look like this:

system_level_control:
   control_connections:
     - [battery, system_level_controller, [SOC, battery_electricity_SOC]]

I'd imagine that most connections would be length 3 connections like above. H2I could easily handle these connections in add_system_level_controller() and the SLC baseclass could easily handle this in its setup() method, by looking at these specific connections provided in the slc_topology and looking at the destination name. I suppose one tricky part is handling the units - but perhaps existing logic in the SLC baseclass can support that or that information can be provided elsewhere in the SLC topology. This would be most relevant for system level controllers that are probably more architecture-specific and more advanced in their logic. This would likely be a follow-up to resolving Issue #748

Start by reviewing H2I's add_system_level_controller(), the SLC base class setup() method, and the existing technology_interconnections handling. Compare the proposed control_connections structure with the slc_topology and Issue #748, including how destination names and units should be represented. Done means agreeing on the connection model and implementing consistent handling in both H2I and SLC.