The Electronic System Architecture Modeling (eSAM) Method
Chris Watkins, Gulfstream Aerospace Corporation
Published: 18 May 2022
Hello. I am thrilled to be with you today to share with you our work in using MathWorks' new tool, System Composer, to model system architectures to address some of our needs in modeling electronic system architectures. My name is Chris Watkins. I work at Gulfstream. At Gulfstream, we design and manufacture the world's leading business jets. We excel and lead the industry in terms of luxury, in terms of speed.
We fly just under the speed of sound, at Mach 0.925, the longest range, and the best of reliability. So you're not going to get stuck somewhere. I can tell you from firsthand experience, this is the way to fly. So who am I? I'm Chris Watkins. My email is shown here on this slide. I'll show it again at the end in case you have questions.
I'm happy to answer, and we're also looking for partners if you're interested in learning more and participating in our modeling method. I'm a senior project manager in our Flight Deck Innovation group at Gulfstream. We are a research and development arm that is looking to bring new technologies and innovation into our flight deck, which is also known as a cockpit. You can see, on the right, next to my profile picture, that's our Symmetry flight deck, which I am proud to be part of the designers for. I'm biased, but I believe it's just a stunning flight deck.
And we're now working on, what are we going to do for the future? My educational background, I'm an electrical engineer in undergrad. I have a systems engineering degree for my master's. And the relevant experience today, you're going to learn about integrated modular avionics architectures, or IMA. I'm a system architect for many IMA systems.
It's essentially a computing platform that you allocate functions to that are hosted on the aircraft. I think this is also relevant in other domains, certainly automotive, internet-connected architectures, Internet of Things, large system of system architectures. So I think there's a number of applications. This isn't necessarily just aviation-specific.
I've architected IMA systems for the Boeing 787. It's called a Common Core System, or CCS. I worked the IMA system for the Chinese COMAC C919 aircraft. I worked a few military programs, and I also brought it to Gulfstream in what we call the Data Concentration Network, or DCN.
I'm an associate fellow at the American Institute of Aeronautics and Astronautics, and probably most relevant to this talk, I have stood up at Gulfstream as the model-based systems engineering champion to take our current practices and then grow them to further improve our development practices and efficiencies. So we have named our modeling method the Electronic System Architecture Modeling method, or ESAM, because we are integrating electronic components at the communication or data exchange level.
We had, from our previous programs that I worked, a number of lessons learned or bruises, if you will, that I really wanted to address with some system architecture modeling. So we started pulling together a vision back in the 2016, 2017 time frame. And as we built that vision, we started to want to look for tools, modeling tools that could help us realize that vision. And one of the requirements was to integrate with MathWorks Simulink for our software behavior models.
Well, in 2018, we learned about MathWorks working on a new tool that wasn't released yet called System Composer to model system architectures, and it was built on top of Simulink, so you couldn't be any more integrated with Simulink. The tool was exactly what we needed. So we started to partner with MathWorks and work with them to help realize our vision using their tool.
And then ESAM is really the way we codify or standardize the way we model within System Composer to specifically realize our vision. We plan to roll this out not only within Gulfstream, but to our supplier base so that when they deliver their systems, they're also delivering an ESAM-compliant model of their system in System Composer that we use to manage the communications and systems integration as well as the configuration of the platform to support their systems.
We had three basic modeling goals. Number one, we wanted to standardize our electrical ICD, or Interface Control Document, which defines all the communications between systems. And you'll see here in this presentation, we hadn't done that yet. It's a simple task, but we needed a good solution for that.
Number two, we wanted to manage our systems integration graphically. We manage our integration today with tables and low level XML files, as you'll see, which is a difficult way to really comprehend and understand how everything is integrated together. Number three, we wanted to drive the configuration of the network right from the model using a model-based approach. And so that was our goal.
So to help you understand our problem statement, I wanted to share with you the IMA architectures in short and brief. So to do that, I want to describe initially the traditional federated architectures that are onboard aircraft, where everything is directly wired together. So as you can see here, we have, in this simple example, a sensor that's connected to a box on the aircraft, which in aviation speak, we call a Line Replaceable Unit, or LRU, and is communicating ARINC 429 communication bus, which is a common aviation bus.
We have other buses on board. The LRU may connect to some effector out there, some valve that it's turning. Using a CAN bus, Controller Area Network, which is common to automotive, we use it in aviation, and is actually standardized in aviation as an ARINC 825.
And there's other communication protocols. It can even be as simple as digital discretes, continuous analog signals, such as a voltage or current to represent a value. But in any case, everything is directly connected, so the wiring represents your integration.
And then we bring in IMA. So the IMA provides a shared backbone. And typically, it's an ethernet standard in aviation, which is called ARINC 664. It can be any other kind of communication bus, but it's a shared backbone. And then we have IO gateways connected to that backbone that transfer data on and off that network from other communication protocols, for instance, ARINC 825 or ARINC 429.
This provides tremendous flexibility and integration because we can now integrate systems with dissimilar communication buses. We're able to translate the signals in between if we need to to flip bits or add additional logic. Lots of benefit. But when the system engineers see this, they go crazy. And they were not real happy with me when I brought this into the company because when you look at it, you have no idea how or who the LRU1 is connected to.
It's directly wired to IO Gateway6, but you can't see by looking at this picture that it's actually being communicated to the sensor and to LRU2. You can do so if you really drill in and follow some of the signal flows deep in the definition of that model, but it's not very easy. So the network data routing is really what defines the integration. And we need a much more effective way to model that so that people can more easily understand this integration.
So in today's workflow, it's in that dotted line box, you can see that we manage our configurations in XML, as I mentioned, and that's how we integrate our systems. And it's a very low level, almost pseudo-code-like. And our systems engineers have a little bit of trouble really interpreting and understanding that. I actually have bruises from bringing all our suppliers together initially on our G500 program and training them on how to define their system I/O, all their communications, in this XML format, and it did not go over well.
And we quickly realized that was not going to work. So we reverted to allowing them to submit their ICDs in whatever format they felt best. Could be Excel, Word, PDF, what have you. We then had our expert ninja team that would translate that over into the XML.
Now, when we did that, we had to validate that we weren't screwing their data up or invalidating what they had defined. And then every time they create an update, we have to manually import it again and make sure we didn't screw it up. A lot of tedious work. We were very successful at it, but it takes a lot of brute force work.
And then when we were done, it's hard to understand. There's literally tens of thousands of these XML files on an aircraft that define all the data flows. And systems engineers need to go through and read these, interpret them, and they ended up using Visio to try to produce a visual representation that they could understand. Even our certification authority has made us take complicated data flows, and they required us to develop these Visio diagrams.
So I'm really excited about the future. We're headed towards using MathWorks System Composer to basically take care of all of this. The suppliers will deliver their ICDs in a System Composer ESAM-compliant model. We will then take those models, integrate them together at the aircraft level. This is a Visio-like modeling environment with component boxes, ports, and connectors, but it's much richer than Visio.
And then when we're done, we're going to use the lower level IMA platform tools to use the APIs within System Composer to pull that information out and then auto-generate those XMLs right from the model using that model-based development approach. I'm very excited about the future workflow.
So a lot of people ask me, well, how is ESAM different? Why not just use SysML? There's lots of modeling methods out there. So there's a few things specific to this allocatable IMA platform that are important to understand.
And first, we needed a way to efficiently distribute the modeling effort across the different roles in a system. So the IMA platform model needs to be defined to define the base network switches, the I/O gateways, the shared processing resources, but there's no system functionality hosted or allocated to that platform model.
And then the system modelers that are modeling things like the landing gear or environmental control system or flap control system, they produce a model of their system that is much like the old federated method, where everything is directly connected because they're not representing the DCN platform. They're representing how their boxes communicate, even if it is across the platform eventually.
And then Gulfstream is responsible for taking those components in each system model and allocating them to the platform using the allocation editor. All three of those components together really form our complete architecture model. That allows us to get to that endpoint that we need, but we're able to model in a format that's much more friendly and much more easy to understand from a functional integration. And then from a physical integration, we have our complete architecture model at the end.
So this approach allows us to have a good role-based modeling approach. It provides independence between the different supplier models that are modeling their systems because they are competitors with each other that can't be working on the same canvas to model their systems. And then the System Composer provides an excellent dynamic modeling environment to create views to take that large model and break it down into small pieces through auto-drawn views.
So we also employ what we call a hybrid system model. So traditionally, in methods like SysML, you break your modeling method between a logical model and a physical model, where you model all your hardware down in the physical model and the communication buses and then the software and the data communication up in the logical model. And in this case, you even have to reproduce components that don't have software, like a simple sensor measuring temperature, but you represented a software and represent the data value that it's producing.
In the IMA domain, using the hybrid approach, we actually mix the hardware and software together in one hybrid model. And again, this gets us back to that fundamental, let me just see how everything flows together in a simple model. And then we allocate that. The system integrator at Gulfstream will allocate the port on that sensor to a specific port on a specific I/O gateway. We will allocate the controller software A to a specific host and application processor, such as Proc1.
And through this method of allocation, of allocating a hybrid model to a platform model, we get an easy to understand model from the system supplier. In addition, they're not responsible for allocating which IO gateway that they're connected to. That's a Gulfstream responsibility. So they can't produce a model that shows that allocation. So this allows us to separate those areas of responsibility.
We also model messages independent of the raw data that exists within the message. On an IMA platform, we have that data gateway functionality, where data from a controller, on a 429 bus, for instance, can publish a command. And then on the other side of the IMA platform, we have an actuator that's got a CAN interface that's receiving that same command in a different message protocol. So we want to trace that message across message protocols, which requires us to model the data in addition to the message itself.
From a terminology standpoint, any data that's being published to the platform we call Published Data Parameter, PDP, and any data being received as Subscribed Data Parameter, or SDP. When we model the message, you can see all the protocol bits within the message, and you can also see the payload where the PDP command is inserted into that label.
So this allows us to track, again, if you're in the lab, you need to know the bit-level definition of the message. If you're just wanting to understand how the systems are communicating and what data they're communicating, you're most interested in the actual raw data parameters.
So there's some other key concepts in the ESAM method, and one is I want to show you the data model that we use. And I actually have a demo here to show you how easy it is to model the data within this ESAM method. And this is important because we're rolling this out to the masses within Gulfstream and our supplier base. This has to be an easy modeling approach that doesn't take a lot of training.
So we model the communication ports as a port on a component, as a root port on a component. And then we apply a stereotype, which includes all the metadata to describe that port, including the connector PIN definition. We define the data parameters as an interface, and there's a couple interface types. Starting in 2021, there's not only composite data interfaces, but also value types. We're going to use value type in this example.
And we can even create a group of data parameters as a set, as a composite data interface, and then reuse that on multiple ports. Then you manage it as a group, and you can modify it in one place and then find ways to just update all of those ports at one time by modifying that one group definition.
So let's go ahead and show you this demo. We do have a customization here that we worked with MathWorks to create that helps guide the user through this ESAM workflow, which we'll be using. So first, we'll create a root port, and we're going to call it ARINC 429, but more formally, we're going to use the stereotype information here on the right to define the port as a 429 port.
And then what we're going to do is we're going to define the properties of that port, and we're going to define that as a low-speed port and then define the connector PIN information. There's two PINs, and they're assigned to connector J1, PINs 25 and 26. So once we have the port defined-- oh, actually, we're going to also define that it's a DCN port, which means it needs to be allocated to our IMA system, called the DCN.
We're also going to define the data that's assigned to that port, and it's going to be defined as a value type, and we're going to call this HeightAGL because the radio altimeter measures the height above ground level. We're also going to define HeightAGL validity to show you that using this method, you can assign multiple interfaces to a port, which is different than the standard way of allocating interfaces to ports.
So we select them. We right-click using our customization, assigned data parameters, and then if we go to the port, we see that the port view shows that we have both parameters assigned to that port. The port's defined as owning its own interfaces, which allows it to own multiple interfaces.
And then we have another customization using a message editor app that allows us to define the messages. Messages are modeled inherently as a composite data interface. But this provides a richer interface to model according to that ESAM workflow. So in here, on the left, we define our base messages. In this case, we defined an ARINC 429 label called a L164.
And then we go into the middle, and we add signal mappings to that message. We include all the protocol bits, things like SDI, Pad, Parity, SSM. But you also see, we included HeightAGL as the payload. So we included that data parameter as part of that message. And then this gets saved again in a message to add a dictionary as a composite data interface.
And then we assign both a data parameter and that message to the port. So when we view the port view on that radio altimeter, we see we see both the DP and the message. We've also defined, in the ESAM method, how to reuse parts using a template instance approach. Within aviation, there's a lot of redundancy so that any single failure is not going to take out one of the aircraft functions.
And we don't want to have to define the same part over and over again. We want to define it once and then instantiate it multiple times. So I'll show you here is we have a radio altimeter system, and we're going to instantiate that radio altimeter part that we just created. So we're going to do that by bringing over a standard component, and we're just going to call it RadioAltimeter1, and we'll bring another empty component over and call it RadioAltimeter2.
And then we're going to use this customization to, again, walk us through the ESAM workflow, and we're just going to right-click on that component, say Create Part Instance, and then that's going to bring in a dialog box to select our template model, which was RadioAltimeter. Create the instance, and then now you'll see it brought in that model with the port definition, all of the data parameter and message definitions.
And we do that both for RadioAltimeter1 and 2. However, they're both publishing the exact same data in the system, and what we really need is to have two instances of that. We need a channel 1 and a channel 2 so that systems know that they're subscribing to channel 1 or channel 2 of radio altimeter.
So we're going to instantiate the data parameters on the port. We're going to add channel 1 as a postfix. Then you'll see what that does is that customization adds additional data dictionary entries for channel 1. And it also automatically assigns those to the port where we instantiated the parameters.
So we'll do the same thing on RadioAltimeter2. Again, this time, we're going to add a postfix of channel 2. It's going to add those to the data dictionary and then assign those channel 2 parameters to the port. So this provides a good way where we can manage, again, the definition of HeightAGL in one place, but then we can create instances of that as channel 1, channel 2 that are applied to our instances within our model. Very exciting.
Layered modeling. So this is one of the things we were actually looking for in a tool and System Composer provided, where we don't have a flat canvas with all detail. We have a drilldown method where at that high level, we have a subsystem with external ports communicating in and out. So that's level 1.
And then we interface and integrate the subsystems together at that black box level. But we can drill into those subsystems to see subsystem 1 has a couple internal components with internal communication, and then any external communication is brought out to the side to root ports of subsystem 1, which is what we use for integration. You can then drill down further to see the software architecture model within one of those boxes, the LRUs.
And because this is built on Simulink, you even have the ability to then create the software behavior model in Simulink, which is directly part of this model that you can just click right into. It's phenomenal.
So there's other System Composer features that we use that's not necessarily part of the ESAM method. We organize our dictionaries into shared and private data dictionaries so that we can keep some of the internal data private between suppliers and then just share the external data. Edit time checks just came out in release 22A. It allows us to, at a time, get feedback if we're modeling something incorrectly.
I've already shown you the power of MATLAB scripting and customizations. It's truly amazing. You can do just about whatever you want to orchestrate a workflow using that method. You can simulate architectures with multiple software behavior models in your system. You can use sequence diagrams to validate that you have all of the signal flows that you need between systems.
There are some additional applications that we don't have time to go into detail here, but I wanted to mention, there's customizable reporting so that we can take this model and then output the interface control documents in more paper or PDF form that we need for certification. We can generate system description documents or the content thereof of the architecture that you've modeled. The functional dependency diagrams. So within aircraft analyses, we have to know which aircraft functions are feeding into other aircraft functions, especially when we start getting into safety analyses and functional failures.
As I mentioned, signal flow analysis, we need to be able to track our signals from one end of the system to the other. We need to know, who are all the users of a signal that I'm publishing out of my system? And then the functional failure analysis related to functional dependency diagrams. If a component fails, we can create reports of all of the aircraft functions that could be impacted by that component failure.
In terms of future work, we're looking at integrating more in with our safety analysis team and their tools. We're looking to add power bus models to our data modeling in ESAM. We're looking to see how we can integrate in with our wiring schematics tools because a system model is pretty close to a wiring schematic. We're also looking to bring in Simscape to bring in some of our physical modeling as well.
If you want more information, we have a couple publications. One in 2020 was our first ESAM publication, "System Architecture Modeling for Electronic Systems Using MathWorks System Composer and Simulink." You can find this on IEEE Explorer. It was published at the Digital Avionics Systems Conference. We're planning to do another one this year at the 2022 DASC conference that's focused on the data modeling. It goes into a little more detail than what I was able to show here today.
And again, we are seeking ESAM partners, so please contact me if you're interested in learning more about this, you have any questions. If you want to practice modeling in it to evaluate it, I would love to work with you. My email and phone number are there. And I want to thank you very much for your time today. Thank you.