I remember it like it was yesterday... I was trying to get a new LON system tied into an existing building automation system and it was chaos.
I had broken every system integration rule on this project and the project was only a week old. In my defense I had yet to learn the process I am teaching you, I tend to have a "adventurous" personality...
So there I was, no as-is system analysis, oops...
Figuring out the use case, to-be systems, and doing a gap analysis... fugetaboutit.
Yep, headstrong and learning from pain, typical Phil Zito.
But you know what, there was one thing I did right, after all the things I FUBAR'd (Google that one :-D ). I did figure out how to map out the physical and logical integrations. And that, SBA Nation, is what I am going to teach you in this post.
By the way, this is part of our Ultimate Guide to Systems Integration.
Summary of Lesson #5
At the end of the day, systems integration comes down to two things: Physical and Logical integrations. That's it, all this use case, gap analysis stuff.. It's all well and good but the rubber meets the road when you go to execute your integrations.
That's why, in Lesson #5, I will be teaching you a step-by-step process to detail out your physical and logical integrations.
Lesson #5: Detailing out the physical and logical integration points
Don't misunderstand. Without a use case and gap analysis, you can get your butt into a whole heaping mess of trouble.
Oh, those were supposed to be BACnet/IP cards on the rooftop...
I've lived in that world, I've got the battle scars.
But, even if you do the perfect use case and identify every single gap in your design, you still haven't created anything until the wires are connected and the code is written..
So, what is our next step? How can you go from concept to working systems integration?
In order to do this you need to detail out your physical and logical integration points.
But what are physical and logical integration points? And what exactly does detailing them out mean?
Well, my friend, I'm going to answer those exact questions below.
What are Physical Integration Points
When folks think of systems integration, their minds usually don't go straight to the physical integration points and that's a shame! I would argue that without physical integration, nothing happens.
You can write the best code in the world. You can take two completely disparate data models and make them one. But none of that "stuff" matters if the two systems can't talk to one another.
And that is why I start with physical integration points.
What are physical integration points you ask?
Physical integration points are the physical connections between the systems you identified earlier in your gap analysis and use case. These physical connections can be direct cabling, networking, wireless connections, the list goes on and on.
The important point is that physical connections, physically connect the systems...
What are Logical Integration Points
Logical integration points on the other hand, don't physically exist. You can't go to Home Depot and pick up 20ft of logical wiring, well if you can let me know and we can make a killing on Amazon...
Logical integration points are the connections between the systems that utilize the physical connections.
For example, you may physically connect a lighting system to a building automation system. But, without a logical connection to tell the two systems how to communicate and to resolve data and all sorts of other "programming" problems, your integration may be a dud.
How do you "detail" them out...
So then, how do you make all this integration "stuff" work and what the heck is detailing something out...
Well, here's the deal, every systems integration job is unique, can we all agree on that?
Ok, I'll take that virtual head nod as agreement :-D
So, if every job is unique it makes sense that we would need to plan out each project and "detail" out the plans for each step.
Well, in this section I am going to teach you my 3 step process for "detailing" out physical and logical integrations. You might want to go grab a pen and pencil for this, don't worry I'll wait for you...
Ok, you ready? Here are the steps:
Step 1: Identify Your Physical Connections
Ok, well that was obvious...
But was it?
Using our use case from the previous posts, we can map out our connections.
If you don't remember our original use case, or you haven't read my other posts (naughty, naughty...) then here it is.
We want to integrate two building automation systems into a single graphical user interface (GUI) on a new system.
Which systems connect to what?
Do you connect the two building automation systems directly to the new GUI?
You need to look at your use case and follow how the systems are supposed to interact. Then, you need to draw your physical connections on a piece of paper. Specifically you should cover:
- Which systems are there?
- What system connects to another system?
- What physical connection is used?
Step 2: Identify your communication flow
Before we get to the logical connections and interfaces we need to identify how the data flows.
Using the use case from step 1 maybe we are routing some information from the first building automation system into the second building automation system.
Why would we do that?
Maybe the first building automation system controls the air handlers which then send data to the second building automation system that controls the central plant. The important part of this step is that we show that connection.
Could you imagine the chaos if we broke that connection and just simply directly connected the building automation systems to the single GUI?
You will want to know:
- Which way should data flow?
- Is a process in a system dependent on another system?
Step 3: Logically map your logical connections
Well shucks, I could only fit the word logical into that heading twice... Oh, well.
It's important that we figure out how our data is going to be connected to the other system(s). In the case of our single GUI, one of our design constraints is to have a new single database.
Well, what if the data is completely different in both BAS?
We might have to go and create an intermediary database to normalize that data.
You know what that means right?
We've got to map out how and what data flows. In order to that we need to identify what data we are looking to communicate and diagram out where that data goes to.
Questions you want to be asking yourself here are:
What priority is the data at?
Are there any Quality-of-Service (QoS) issues?
Where does the data come from and where does it go to?
Conclusion
Well SBA Nation, there you have it.
That is my secret sauce, my step-by-step process for approaching how to map out your physical and logical integrations. This 3 step process has served me well over the years and I've avoided a lot of headaches because of it.
So, I ask you, what is your process for mapping out your systems integration projects? Do you agree with my process?
Let us know in the comments below!
