Loading ...
Sorry, an error occurred while loading the content.

Re: [bacnet-it-wg] Starting the analysis of FSGIM for BACnet

Expand Messages
  • Dave Robin
    The java and C++ generation used the stock code generators in EA. The CSML generation was done by writing custom language scripts for EA. The CSML
    Message 1 of 3 , Dec 14, 2012
    • 0 Attachment
      The java and C++ generation used the stock code generators in EA. The CSML generation was done by writing  "custom language" scripts for EA.  The CSML post-processing (inheritance walking, urtype finding, and error checking) was all bash. Grep and sed are my friends. I'll be happy to share either with anyone who wants to play with them. 

      --
      Dave Robin


      On Dec 14, 2012, at 1:28 PM, Chandra Appanna <chandra.appanna@...> wrote:

       

      Did u use Enterprise Architect for the code generation or
      another tool?

      Thanks,
      Chandra.



      From: Dave Robin <yahoo@...>
      To: XML-WG <BACnet-XML-WG@yahoogroups.com>; IT-WG <bacnet-it-wg@yahoogroups.com>; SG-WG <BACnet-SmartGrid@yahoogroups.com>; AP-WG <BACnet_AP_WG@yahoogroups.com>
      Sent: Friday, December 14, 2012 6:59 AM
      Subject: [bacnet-it-wg] Starting the analysis of FSGIM for BACnet

       
      BACnet Data Modeling and Smart Grid folks,

      Here's a start at an analysis of the FSGIM (Facility Smart Grid Information Model) that we talked about in Atlanta.

      The model is maintained in UML in Enterprise Architect. But every protocol maker will have to find a way to put that mess of interconnected UML classes into a concrete serializable form. That is our challenge.

      To help understand the model outside of the UML tool, I've produced java, C++ and CSML versions of the model. Post-processing the CSML has led to finding several problems with the model's database and I'll be feeding that back to SPC 201P shortly.

      These java, C++, and CSML representations still represent just an "in memory" form. There are problems with this, as anyone who has tried to serialize out a graph on interconnected objects in memory to a on-the-wire format knows well. Not only is it too big to just serialize out entirely, but in some cases, the graph may even include reference loops, so we have to find a way to break it up where possible while still respecting things that have to be kept together atomically for data integrity reasons (i.e. interrelated things that can't be "read in pieces" with separate messages).

      The next step is to decide what things can be static, identifiable objects and what things are dynamic/atomic. There are hopefully a lot of cases where a "collection of..." can be modeled as a "collection of references to...", but not all contain appropriately identifiable things and will just have to be a collection of instances directly. This is where "automatic code generation" ends and software engineering takes over.

      Start with the "Model Components" package. That's where "our stuff" lives, particularly the energy manager classes EM and ESI_EM.

      (you can ignore comments in the CMSL related to "urtype", those are just some code-generation artifacts to allow post-processing the inheritance tree)

      Enjoy.








    Your message has been successfully submitted and would be delivered to recipients shortly.