 So for those of you who don't know me, my name is Steve Davidson. I'm from Raytheon and in the context of the SOSA consortium I'm the vice chair of the steering committee, which is the governing body for the consortium My intent with this is to get you guys all up to speed on what is SOSA What we are doing in the SOSA consortium a bit about the SOSA technical standard and to answer any questions You have we are going to start off by discussing the fundamentals of what is and isn't SOSA I'm going to tell you a bit about the consortium the organization, so you understand the context Those of you who are there this morning heard me comment about some of the foundational things that We had to agree on to begin this process and I'm going to go over those in some detail because it's very important to have that solid foundation We are going to talk about the tech SOSA technical architecture, which is the centerpiece of the consortium We're going to talk about the business approach And then there are certain things that you have to know in order to be effective within the consortium having to do with very practical things And we're going to go over those as well So any questions before we start? Good All right the fundamentals As you are probably aware the National Defense Authorization Act of 2017 mandates that any programs undergoing Milestone A or B beginning this past January must adhere to the modular open systems approach Immediately after that went into effect the secretaries of the Army the Navy and the Air Force produced this joint memorandum That site says that most of the modular open systems approach is a war fighting imperative They go on to describe how it's going to be included in pretty much everything going forward and they cited four standards OMS UCI SOSA face and victory all of which you heard a little bit about this morning When people say modular open systems approach notice its approach not Architecture its MOSA is an approach That's because it has a business aspect which includes things like contracting language and intellectual property Acquisition processes and so forth and it has a technical side which includes modularity and the use of open systems Architectures now there are a bunch of architectures that call if I is open system architecture I'm listing here the ones that were mentioned in the triceratist memo, but there are many many many architectures out there So when you say MOSA you're referring to an approach when you're talking about open systems architecture osa You're talking about the way those are instantiated in the technical documentation Okay The word architecture is often confused, so I'm going to explain what we mean by architecture and How it differs from design so this is my favorite definition of architecture? It's an IEEE ISO IEC definition fundamental organization of a system embodied in its components we're going to use the word modules here because we're about the modular open system approach and Their relationships to one another and those relationships are interfaces, so everything in MOSA in terms of what we're doing here in terms and it's so so are based on the concept of modules and interfaces a lot of people confuse Architecture and design Think of it this way a design is an instantiation of that architecture and there are many ways of instantiate I'm going to do some examples in a bit, but there are many ways of instantiating an architecture in specific designs so When we talk about what we're doing in so so we are developing a reference architecture that can be used to instantiate a whole wide variety of systems and that is the whole point and My little bumper sticker is that what's really important is that we are not generating a point solution We are not generating any a description of a system The whole idea is to have this unifying architecture that Covers a wide a variety of systems as possible and you this morning heard the government Desirements on that and it's going to they'd like to see it doing everything from soup to nuts Ideally if you're talking about a radar it'd be great to do it be able to develop an architecture that applies To to everything from a joint-stars class ISR sensor down to a police radar speed gun There are practical implications for those that the wide wide scope First thing I think of is like design school and user interfaces Commercial definition of design why why do we use design when we're talking about instantiation? So you talked and I'm going to repeat the question for a video So when you're talking about things like user and user interfaces and so for those are actually instantiations And in fact the user interface is actually outside the scope of what the socio-technical standard is going to define So as we go into Architecting and in architecture and what what a reference architecture does for you I'm going to give you some clear examples of the difference between architecture and design okay, as I mentioned before we want to think in terms of modules and Interfaces, so what is a module a module is a grouping of functionality encapsulated in a module that exhibits certain behaviors, so it performs functions and exhibits behaviors and Those modular entities then interact with other modules in a system over key or well-defined interfaces Those interfaces could be signaling in they could be physical thermal There are a whole lot of definitions of what your Examples of what you might be about interfaces But if you think in terms of defining an architecture of a system in terms of major building block elements And then how those building block elements Interact with one another and there's some criteria and we'll talk about the the Sosa criteria for how you decide What your particular modularization needs to be how you group things and why you group them And then that's a very very important thing to cover and we'll get to that so I'm kind of laying the foundation So I've already mentioned that modularity encapsulates functionality and behaviors Ideally and one of the tenets of Mosa is that those modular entities are tightly integrated Within themselves, but if in all practical purposes loosely coupled from one another Now the word open gets abused a lot. It's kind of like free. What do you mean by free? We're talking about free beer free software free and open And in fact there's an essay out on the internet if you can you can search for it called 50 shades of open We're going to use the terminology in the definition based on Mosa documentation And there's three things that you need it really there's a lot of paperwork there But it all the balls down to three things that the definition of the architecture is Widely available and published Great, but that's not enough There needs to be a consensus-based process For governance and definitions so that their terminology interested parties have an opportunity to participate and influence the process And that's that's why we have this consortium and the third thing and you heard a bit about that in the opening session this morning Is that there's a conformance or val or compliance validation process that ensures that if you say that you are using an Adherent to that standard that you really are You all familiar with the term Wi-Fi You probably also heard of IEEE 802.11 g So the IEEE is an organization that developed the standard How do I know that that my widget that speaks 802.11 g and your widget that speaks 802.11 G actually can interact well We can both build something to the standard and hope that it's going to work industry group was formed called the Wi-Fi Alliance and They defined a set of tests that determine and prove that interoperability and the word Wi-Fi you cannot put that Wi-Fi sticker on your device Unless you have been proven to you can prove that you've passed their tests If you try to use the word Wi-Fi and they haven't just as the open group would do for the SOSA Trademark they will come after you so this conformance process is actually baked into MOSA documentation Yeah, if you if you claim open you have to have all three there are organizations that publish their own internal standards and say This is in certain name of company open that doesn't make it open just because you publish it Doesn't mean it's actually open one of the things it's critical in the concepts of open systems architecture is the gray box concept and And and you you probably noticed that and not by accident that my little picture here all of these boxes are gray What do you mean by the gray box concept gray box concept says that the standard defines? what the functionality is and Defines the interfaces, but it is absolutely silent on how you instantiate that process So inside the gray box, it's not a black box because I know what the functions are It's on a white box. I don't know what you did inside there, but I do know that you encapsulate these functions So I'm gonna give you an example and we're also going to get into the design versus architecture I have here behind the podium an invisible lamp You guys can't see it, but it's really here now. This lamp has three modules. I'm gonna unscrew the top There's a shade and put the shade aside. We're not going to worry about the shade But you know that I can buy another shade replace it. It's beige. I'd rather have white cool. I Have a base. It has a little wall plug that's dangling on the floor here and I can plug that into the wall That's one interface and the other interface is a socket. It's an a 26 sorry e26 socket e for Edison because Thomas Edison actually invented that in the US We all get and get light bulbs from that now unless I bought this lamp. I Can unscrew the light bulb and we put it down so it doesn't break I'm sure I'm gonna get in trouble for that statement So unless unless I wear where the lights are physically, you know, soldered in I can replace that light bulb with a new one Especially if it burns out, it's very important Okay, so the three three modules here one of the modules is a light bulb now. How was that light bulb instantiated? I Could have instantiated this light bulb by taking a thin piece of tungsten and putting it in an evacuated envelope glass envelope and Running a current through it and that tungsten filament gets hot and I produce light I Could also instantiate this light bulb with this one which has this you can't see it, but it's a little curly queue of glass Compact fluorescent or I could pick up this light bulb and Attached to the e26 base is a little power supply that turns 120 volt AC into 5 volt DC And then soldered in there is a whole bunch of little LEDs and then it has a diffusive cover three different designs One module so differentiation between design and architecture. I Think you guys get the idea. I don't the beauty of this is I don't need to know general electrics Formula for generating that tungsten filament in order to replace that light bulb So you can see how this factors very nicely into the concepts behind mosa The government wants to buy the systems made up of modules where the functionality interfaces are defined But they don't want to they don't we don't want to give away the IP and they don't need to know the IP for them to replace This module with another an example of this in your everyday life is your car You have a radio system in your car and there was a time where you could just replace the head the radio head the the audio system the AM FM radio cassette deck with a third-party one You can add a cassette deck to a car that didn't have one and not have to replace the entire dashboard because of that idea of Upgradability and that's part of the concept behind mosa and why the government wants mosa in in all of the procurements So I've answered your question. Okay, so the the question was I'm repeating for video they There are some concerns about the interoperability between modules and different instantiations And how do you ensure that you don't have many you can mitigate interference? Okay, so first of all one of the ways you mitigate interference is to make sure that you can manage And coordinate the operation of these things those have to be built into the architecture if the architecture doesn't take it into an account Which is why that was brought up this morning So things like resource management to ensure that that if you if you're sharing an aperture that only one function is operating in the Aperture at a time that has to be baked into the architecture. It's an architectural consideration Now when you deploy a system There's nothing in the architecture that says that this antenna has to be within or to or this far away from That antenna that that when you're when you're looking for cosign interference. That's an instantiation question You need the architecture be able to monitor when that happens But as you instantiate that that's a that's a design issue. It's outside the scope of what the architecture can define Just as every lamp has a little sticker on it that says, you know, don't use bigger than a 60 watt light bulb There's nothing that prevents some person from sticking a hundred and twenty watt light bulb and burn in their house down okay All right, so our approach for the fursosa is Make sure that we've got Everyone who has a stake Engaged so this is not one of those programs where it's by invitation only we've got all the services engaged We've got industry. We've got other government organizations, and we've got academia our goal is to develop one unified technical architecture that addresses radar eo to EO IR SIGINT EW and communications Now you might say wow wait a minute. Those are all different Are they really they all emit and receive structured energy? They process that energy and they turn it into information or action They might be somewhat different at the place where they're receiving photons That is EO IR is is very short wave radar EW SIGINT communications is usually radio frequency But once you've collected that energy and turned it into electrical signal, there's a huge amount in common Between those and that's what we're doing. We're leveraging that commonality The why is you heard that this morning better acquisition better upgrade I know my organization is very interested in that because we want to build products around standards So that we don't have to invent because it's more expensive to invent than it is to reuse And we're doing that through this modular open systems architecture that is SOSA by defining these Functional aggregations as the modules and defining those interfaces between them faster better smarter, right? That's what everyone's after we want to be able to you heard the discussion this morning about life cycle support the upgrade ability You heard you know, it's cost-effective. It's cost-effective on both sides national defense strategy Mandates a change in how we acquire systems the government acquire systems and how we we develop systems in response And interoperability the idea that that you can build something that Is useful across multiple things in port terms of portability and because you want to build things that can work with other things That they're not isolated standalone. I love it when I see charts like this This is our architecture a lot of people who put up Right, they'll have a bunch of boxes that are going to be arrayed like this and you know They won't label them ABCD, but that's what they say This is not an architecture Anyone want to venture a guess as to why it's not an architecture? Nobody wants to venture a guess. Okay. I'll give you a whole bunch of reasons first of all It tells me absolutely nothing about how a interacts with H or whether it even interacts with H This isn't even a good wiring diagram because if this is supposed to be a network You know that we don't use the old style thick net that existed when I was young that you know You had a big fat wire and everybody did a vampire tap into that wire No, we we go to switches and hubs and and and and so this is not even right because it these things are all talking to a Concentrator, this is not an architecture This doesn't tell you anything about how the system functions. You cannot build a system based on this so What do you do? Well our approach is to use dodaf raise your hand if you break out into a cold sweat when you Hear go dodaf a lot of people do that. Okay It's not so scary the Department of Defense architecture framework is simply a Decomposition of the description of a system in terms of aspects when you have an architecture for a house You have a plan view the carpenter will use that to do the outside part You'll have a plumb a plumbing view which tells the the plumber where the pipes go You'll have an electrical view and then the architecture of the house is the combination of all of those You can build a house based on those that's what dodaf does it divides the system up into different ways of looking at it Some of them are physical like the systems viewpoint and we're going to talk about the SV one for Sosa Some of them are our functional like the services viewpoint. We'll talk about that Some of them have to do with things like the capability. We're going to talk about that first What what are the capabilities and some of the material that you heard this morning? relates to things that we have built into the capability view for Sosa So all dodaf does is allows you to take the system a complete picture of the system and look at it from different perspectives So let's talk about the capability view number one or CV one for Sosa The CV one is was essential when we started this because we had people from all sorts of organizations with all sorts of Perspectives all coming in with a completely different view of what Sosa was going to be and we needed if we're going to make any Progress at all. We absolutely needed to have a unified view of what is Sosa and what we're doing so You probably already read the vision at the top It's business practices and and and technical environment that engages We've developed cost-effective system that can be reconfigured and you heard some of that this morning And in the plenary session the goals are to make it open to make it standardized To make it to harmonize with existing standards to align with DOD policy to be cost-effective and Adaptable again, all of which you heard this morning now for each one of these there a set of Enabling capabilities that are essential to get you there right these are not this is not the idea is not just to have a bunch of vague wish list, but actually put that into practice so For each one of these there's a several things that are the enabling capabilities that are the things we do to make that happen so Under open we're developing an open systems reference architecture through a consensus driven process So we achieve number two of the three things that you have There's a business model That that enables that the acquisition community has to be able to buy what we're what we're Architecting here, or it doesn't make any sense from a standardized perspective We're leveraging existing standards as much as possible and you're going to hear those of you who are going to the hardware working group later You're going to hear a whole lot of Vita a whole lot of host a whole lot of CMOS We're going to create what's new only when necessary And again consensus basis Harmonized And what do we mean by that is you heard this morning? There are a lot of standards and someone asked the brilliant question, and it was a great question We is the intent to just keep making new standards and the answer is no Sosa is look being viewed as the unifying standard and what we are actively doing and we talk about The organization you'll see that there's there's a working group that is set up specifically to align different radar architectures in Sosa, so We're trying not to make yet another standard when we don't need one and there's a great xkcd cartoon about that I would love to put that in here, but I think there's a copyright violation. Yeah, so the question is are they adaptable? We don't know what will be 2030 but the intent move by having a standards organization is to And I think you heard they talked about this morning that there's a road mapping activity going on To continuously update these things one of the things we're doing though along those lines is trying to converge So different standards are evolving and so I've been involved with several others And what we're trying to do is we're trying to move them all in the two words a direction of convergence That is there are things in this one that we don't have there so When I get to the modules, I will give you an example of one Will we changed what we're doing in order to be better aligned with an existing radar standard? Yeah Fundamental what's and why is can to remain constant over a long period of time? Yes, and the specific the specific technologies so the con the concept of standardizing on connectors Thank you So the concept of standardizing conductors isn't going to change the idea is that as new connectors with more capability come online Those then become part of the standard and we'll end up deprecating some of the older stuff just to keep things manageable I Aligned well You know what in the interest of time all of this is on Play-Doh, and we'll come back to it But in every every one of those cases the idea was that there are Reasons why we're doing things and how we're attempting to accomplish them. I can't claim we were getting there We do have some challenges with a large organization like this We have people for we have we have large system Sensor providers we have parts and elements suppliers. We have acquisition organizations. We we have we have government From you know, we have different parts of the government all of which have their own perspectives and needs so There are changes that we have to We have to address We have to deal with the fact that that existing contracting language doesn't really Amen, it's it's not really amenable to to what we're trying to do So the contracting guide offers alternative contracting language to make it possible for someone to Acquisition organization to buy a system based on the Sosa technical standard. We we form this consortium officially Was it a year and a half ago? We've been out. We are operating in an informal way Incubated under the face consortium for a while before that and and we're moving towards developing the business architecture and As well as the technical architecture This is the org chart for the Sosa consortium So there's the steering committee that's made up of organizations that are at a particular membership level and they are ultimately responsible for Final decisions throughout the consortium. We have two standing committees that operate across the consortium The use case standing committee is developing and and and officializing the use cases that we are using to test whether we're accomplishing things in the architecture that we intend to and there's a technical standards coordinating committee that takes all of the Working group outputs and make sure that when it goes into the technical standard and the draft technical standards that is consistent and well coordinated We have an architecture working group a business working group hardware electrical mechanical and software and For each of those working groups or almost each of those working groups We have a number of subcommittees. These are long-term standing bodies that address Important aspects for each of the working groups. So the very first one we stood up with security And I think it's pretty obvious why the security subcommittee was established Fundamentally we want security to be baked in not bolted on to the technical standard. There isn't a separate security architecture There are security aspects to everything Several other standard subcommittees exist you'll notice data model is light here We intend to stand that up. It's just a matter of time leadership and and and manpower Under business working group we have conformance and outreach Hardware has this thing called system management, which originally began as as Essentially chassis management and has grown from there. I'm going to talk about management a little bit And then the radar it's called the officially the radar, but it's actually the radar framework alignment Subcommittee is working across multiple radar standards to try to achieve alignment by making changes to our Technical standard to align with the others and making changes to the other technical standards to align with Sosa So we're trying to find that that happy medium our makeup is industry a lot of defense and as well as as well as commercial And then we have a whole bunch of DoD and and other governmental organizations participate our Membership is divided up into sponsor level and principal level members These organizations are part of the steering committee and then associate level allows us to be as well as is Widely available to small organizations as well as large organizations and yes last night I updated this with the new organizational Mike left. He's our membership guy. He just announced we have a new member Trouble for me is this list keeps growing and growing and growing and I'm running at a speed pace Every working group has a chair and a vice chair. These people are elected by the membership So I'm the vice chair of steering Ilia Lipkin you guys all met this morning is the chair of the chair The purpose of steering is essentially to be the decisional body that represents the consortium as a whole our business working group is chaired by John bowling and Vice chair George Dalton by the way, you'll notice that in almost every case We have one industry in one government person that has not been it hasn't been architected that's way It's just how it's turned out Because the level involvement this is a government industry collaboration so You're gonna see a lot of of combined teams The architecture working group is Kind of the integral integrating element that pulls together all of the parts of the socio-technical architecture again government industry working together Electrical mechanical is the only one that doesn't have a government person in the lead role Their their function is To ensure that electrically and mechanically we have a sound Architecture I'm gonna be talking about the products of all of these working groups Which will be a lot more interesting Software working group again government industry team And their responsibility is the software aspects of things Especially as it relates to the interaction between and their faces between the modules And then the hardware working group has focused quite a bit on plug-in cards In the Vita world you'd call those modules, but in the social world for reasons that hopefully you become extremely apparent in a moment We refer to them as plug-in cards and then finally the use case standing committee and their job is to collect adjudicate and and Flesh out all of the use cases that we are using to test out whether the architecture makes sense I Will not talk through but every one of the subcommittees has a charter and and And is well-defined by the way these charts are on Play-Doh, and I'll show you where they are in a little bit We also have these things called task teams now What is a task team task team is a short duration small group that's supposed to go off and figure out some thing And then come back with it with what they think is the answer There they're specifically to be short duration. So security is going to be with us forever But we have a number of task teams that are out to answer one question one question only and then Evaporate and that's to make sure the organization doesn't keep growing and growing and growing Okay So let's get back to the Sosa technical standard and our approach We recognize and I've been on standards bodies where Everybody comes up with their cool idea widget and you kind of build it up bottom up You don't build a ship by throwing a bunch of deck deck boards and and so forth and and sort of You know one molecule at a time you build a ship by laying a keel add some ribbing start putting that the You know decking in start putting on the hall then you fill in the inside We're our attempt is to do the same thing is to build the structure and then fill in the structure the details So we are following a top-down approach and we are following the DoD most of guidance that I showed you before This chart was formulated probably two years ago. Maybe two and a half years ago as to our process We started out by saying who are the stakeholders who cares about what we're doing here And who needs information from the social technical standard? We developed a consumer product matrix and I'll explain what that is but essentially If you are following dodaf you don't do AV one then AV two then AV three then SV one then SV Don't do that you define what you need and you don't do all of those representations So the question is what do we need to produce in order to generate a technical standard that people can develop to? We identified our objectives. We developed quality attributes. You're gonna hear about those in a little bit We developed architecture principles. We developed and then stopped developing use cases You'll notice this is yellow and we are still talking use cases The history of that was that we started down this path And it was a long path and we weren't getting these things done and people felt that that we were getting behind Where we should be so we stopped where we were We started doing this and now we're going. Oh my goodness. We need more of this again So we are back to generating use cases hence the discussion this morning hence the meeting this afternoon the business drivers leading to leading to things like the the Backplane meeting tomorrow I Was very involved in the face consortium for Most of its early years and we learned a very big lesson then Every product of the face consortium had its own glossary its own dictionary and When you start looking at those dictionaries you found we found that some of the definitions not match They didn't even look the same So with Sosa and by the way face has since the face consortium has since reversed that they now have one integrated AV2 but We started out saying we're not going to do that We are going to have an integrated dictionary and all the terminology to make sure we're all speaking the same language because within a big Organization if you're not speaking the same language You're not going to accomplish anything We defined the system boundary We started defining and then we we did define the the the the module and we're working our way through defining the interfaces between modules So that's the big picture of where we are color-coded. I Mentioned that the very first one of the first things we did was to identify who our stakeholder community was and Then what are their informational needs? So this is very hard to read. I'm going to zoom in in a moment but for each category of Consumer we identified what their informational needs are so an engineering organization within government is going to be interested is what the functional decomposition is a Validation organization is going to be looking for Sosa unique certification Activity and they need to know what the system behaviors might be etc. So zooming in a little bit what we did As we said okay for each information need These are the artifacts that you could produce and where do you have an intersection so The someone who needs to understand the social technical architecture and interactions and especially engineering use cases are going to need these products and someone who needs How it can help? Program managers high-level of information, you know, etc so then what we simply did was we looked at where the intersections are and Where we found a preponderance of need and we said those are the artifacts that we need to generate in the first round for the first version of the standard So we identified what we are doing before we even started So this is the the the development roadmap for the different Products that that we we're we are doing you know CV one we've done the AV one AV two is all done The conceptual data model you're going to see we've done that etc But we're in the process of defining the logical data model and we have little fragments of the physical data model So what does that all mean it's okay So let me start us back on the previous flow chart and say quality attributes Quality attributes, they're not quantity attributes or quality attributes are the things that you use to evaluate the goodness of the Architecture in the context of the use cases. So what do you want out of your architecture? so there are ten quality attributes that we have for Sosa and By the way quality attributes are also rank ordered So interoperability Trump's Portability you say well why is that well the result was the result of a lot of deliberation and a consensus You can't have it all you have to sometimes make trades now if it's on the quality attributes list It's still part of the evaluation. I'm not saying that the one at the top always wins. In fact You tend to be banded so our quality attributes are interoperability Securability modularity compatibility portability to be continued and for each of the quality attribute and you probably can't read it from the back of The room, but it says what do you mean by capability or compatibility and then there's a statement of in the context of the Sosa Architecture this quality attribute in this case refers the ability of Sosa systems to be used with or integrated with Systems not designed to align to the Sosa reference architecture with systems designed with earlier versions of the Sosa standard So we have backward compatibility So what do you mean by it and what are the implications for the architecture and all of our decisions are couched in those in those terms? So somebody comes up with a great idea It's evaluated against this and some of the other foundational criteria the other ones are plug-and-play plug-and-play ability upgrade ability Scalability in two contexts sensor multiplicity and host size because when you say scalability What do you mean? And we had two different interpretations and then resiliency and what do you mean by that? Refer to your build a Sosa system to be able to maintain operations while under duress caused by physical damage electronic interference or cybersecurity attack So those are all of the quality attributes that we baked in another foundational concept our architecture principles Architecture principles are guidelines to the people working the architecture So we've got it's not like you have one architect. You're all architects far as the consortium concern. You're all architects So the the architecture principles address some things are business related some things are technical, you know So so you know every Sosa hardware element has defined physical interfaces Modularity is fundamental interchangeability is fundamental each of these is described. There's actually a lot more information to it What is the rationale and what are the implications and and I am not going to read this to you Please read this on your own, but what it is the statement of what you mean? What is the rationale and what are the implications for the Sosa technical standard if you integrate all that information up? You will you will essentially have the stuff that Jason was talking about this morning earlier on I said we're doing radar EW SIGINT EW and communications and I posed the question cheese. Well, that's a lot of stuff I mean the whole point is to be able to maximize commonality The back end and I don't like that term, but the back end of a EW system or the back end of a SIGINT system is doing pretty much the same thing as the back end of a radar if you're working with a SAR image and you're working with in a Photographic image you're doing the same thing your geo your geolocating your rubber sheeting it You're moving things around so that your your your image matches geographic References and so forth so we are our objective is to maximize the commonality between systems because ideally you would have a Sosa sensor That's multi-headed that might have a SAR and a SIGINT sensor in one head So you've got maybe two different apertures all feeding the same processing chain and working together The AV2 the integrated dictionary. This is just little pieces of it So some terms that are very important a hardware element is a general term a Plug-in card is essentially something that slots into a backplane a Sosa plug-in card is not just any old one But one that actually conforms to the Sosa slot profile A software computer component is a chunk of software and then a Sosa module is an architectural entity that does the business of What a sensor does so one of the reasons why we don't use the word module to refer to a plug-in card is a Single-board computer lacking software doesn't do what a sensor needs it to do You need that tracker you need that you know the the the threshold detection you need all of those functions of a sensor to be operating so a module in Sosa speak is a Functional aggregation of the things that need to be done in order for a sensor to work And we'll talk just about that a little bit of doadaf here What is an sv1 lot? How many of you heard of the term context diagram? Few of you okay, so you can think of an sv1 as an example of a context diagram And I'm going to skip a lot of the words here, but I'm going to go to a picture So the way you would instantiate a Sosa sensor physically from a very very top level is you have a whole set of hardware elements that connect with other hardware elements either potentially through a pod or associated with a host platform that Communicate using various interfaces some of them are digital some of which are analog some of which are cooling some of which are power And you way you build a Sosa sensor. It doesn't have to be a monolith You could have some of the some of the some of the you know The apertures could be on the on the front end of an air vehicle and all the processing can be aft inside The key is that these elements communicate through each to each other by way of not custom wires Because we're trying to get away from custom right it's going to space new modular But through a set of interfaces that are defined by the electrical mechanical working group as the interfaces that connect pieces of a Sosa sensor together So that you can replace this aperture with another aperture because it has commonality at the interfaces There are actually two versions of this one where the pod is in is entirely within the cat the Sensor and some where the pod is just a host to two portions of the sensor So when you talk about what is a sensor? It's essentially something that does one of the sensor Performs a sensor functions or a combination of them as in a multi-enter a multi-headed system a Hardware element is a major physical building block of a sensor could be an aperture. It could be a chassis host platform How many of you guys thought before just now that Sosa was all about airplanes? Good, okay, because the host platform can be air could be surface could be essentially subsurface. I suppose We haven't explored that yet Could be a building I mean why not put a Sosa sensor on a building the host platform can be anything and the idea is that What we want to do is we want to make sure that that sensor could be applied in different environments There are certain things that are inside the envelope that the source that functionally the sensor does and certain things that are not So I mentioned user interface before All the data is there But for the Sosa consortium to define a uber user interface that'll work on all systems makes absolutely no sense at all now I've heard Some of the customer community say well, we really want to be able to have a Defined user interface Define it put it on a raspberry pi have it external to the Sosa technical standard, but included in your acquisition There's no reason why you can't do that okay, so Remember we are talking modular architecture Modules and interfaces so when we talk about a Sosa module, we're talking about something that aggregates the functionality of What the sensor does hence the terminology Sosa module Um How we got there well There are a lot of ways in fact very very first or second maybe the third meeting we had we asked a radar person a EO person and an EW person to draw a block diagram of their typical system and there were some similarities and differences But there were differences so we asked the question why are you doing it that way? Well, that's how we do it Why are you doing it this way? It's just traditionally. That's how we partition things So I said well, let's just break. Let's break things down into their constituent functions So we started out with a enormous list of functions and we began to aggregate them We began combining them into modular entities based on some criteria that we decided ahead of time It's got to be it could be has to be severable with minimum complexity interfaces can stand alone independently testable does not expose intellectual property and encapsulate rapid change to Your question about upgrade ability you if you've got something that you expect to be upgraded quickly You want to make sure that that's in a standalone module rather than having to rip a module apart because technology gets better And then we so we we identified What needs to come information needs to come from outside the module to feed the module so the module can do its work But we don't care about the internal interfaces within the module because that's part of the secret sauce. That's part of your IP Okay Again gray box concept we specify what the modules do We do not specify how it's instantiated. We've had a lot of discussions where we get into instantiation space And we have to blow the referee whistle and say stop. This is a reference architecture. Not a system architecture Not a system design So we've identified a couple dozen modules Each one has a number like module 6.9 a label a Description a list of functions a set of inputs and outputs and all of this is you're going to see Snapshot examples of it, okay So this is the list of sosa modules and we've grouped them by Category so these are all by the way, none of these I shouldn't say none of these We are not setting things up so that you have to have all of the modules This is a super set architecture So for example if you've got an EOI or sensor that only needs to send Images to the ground you don't need things like situational assessment and storage retrieval and impact assessment those are important for certain types of sensors like EW But you're not in a necessarily instantiate that in a simple EOIR sensor It's a long list. I'm a visual person. So I prefer the graphical representation And I'm going to walk you through this so we have two management modules One is called the system manager. It's an unfortunate name. It really folks focuses on things like health and status Housekeeping functions within the sensor the other one is the task manager and we'll talk a little bit more about that But the task manager is the thing that communicates with the outside world and receives the look over there at that object or Update a track so the task manager worries about the sensor operation as a sensor The task the system manager focuses on making sure all the pieces are working, you know Everything's lubricated and and has a voltage and so forth your question So the question was how does software and hardware overlay and the answer is so Typically done now you're into instantiation space So we one of the things we're working very hard to do is to make sure that if you want to implement something in Software or he wants to implement it in firmware that they're not locked into well He can't do that because we said it's going to be in software a lot of these functions These modules can be instantiated solely in software like the tracker Some of these functions are implemented in some combination of hardware and software What we're trying not to do is tell you how to do it We're trying to tell you what it needs to do and what interfaces need to be exposed for the purposes of Ensuring that you have a successful System design repeat the question for the for the video. What about interoperability and plug-and-play ability? So a lot of efforts going on right now to figure out a way of for example abstracting things From firmware so that it could be implemented in firmware or software and And at at build time you worry about it But you don't have to it's not a situation where the architecture locks you into one solution or not So that's a hard problem But that's also one of the reasons why we're still working on interfaces because we're trying Say again Yeah, the art one of the architecture hard points is to not force a particular form of instantiation Transmission and reception we've separated receiver and transmit so that you can have for example radar warning receivers And you don't have to carry the baggage of transmit We have a group of modules that deal with processing and signals So image pre-processing or object characterization and then tracking this module used to be integrated with this module The number is 3.4 you would think that would be numerically earlier than image pre-processing or whatever and the answer is no We had it integrated and frost which is an open architecture approach to as an army Architecture came to us and said we think that we'd like to have track or separated. We'd like to converge We want to be aligned with so so that's the only place that we were really different We had many discussions. We worked out the implications We decided it was a good idea to do it and the tracker is now its own module I already mentioned the analysis and exploitation and then there's a set of reporting services And then we have this support or or Service functionality security encryption time nav calibration and the host platform interface The role of the host platform interface is to allow us to be agnostic to what you put this on This this this side of it can speak oms There's a number of things we're looking at oms is the first one that we're working on But the idea is you don't need to bake oms inside the Sosa sensor in order to speak oms to an outside and be part of an ASB Okay, ah Forgotten it's been a while No on now we did a refactoring we realized that there was And in in the sigin and EW community there was a standard decomposition And we had we were not aware of it when we did the initial So we did a refactoring about a year and a half two years ago that then realigned these to an existing In existing body of knowledge because we want to be harmonized So it wasn't that we dropped this one out. We actually Chopped four things into three so for each of the modules and this projector is really kind of fuzzy But we developed a service view one and the service view for in the service view one defines What a module what each modules does so this is there's the tracker and describes And then the functions themselves the inputs and the outputs from each module are captured in the service view for Which is an enormous table that I think we stuck in the appendix of the snapshot just because it was such an enormous an enormous table From an interface perspective, I usually you know with with with apologies to my my networking and communications friends The OSI seven-layer model is is is a little bit of overkill. We don't have a presentation level a session So we look at it from a physical a protocol or a signal and our data Content perspective and you say what do you mean by protocol? You guys have all been on the phone with somebody and you're reading a phone number Phone number is you know 555 one two one three four five six and the other person saying five five five wait wait say it again Because you did it all at once and you expected them to read it back and in fact you might have said I'm going to give you the first three digits and then pause and you're going to say uh-huh and the next three digits So that's the protocol So we wanted to make sure that when these modules interact with each other the protocol used is not necessarily tied to the content of This of the communication So our approach is top-down We defined a conceptual data model don't have speak give one that that identifies What kinds of information exchange the logical data model that talks about the content? And then we are working through we're still not done with this and we also have the physical data model that Defines the specifics of how those bits are communicated. So little indian big indian We talk in double precision floating point. We talk in integer. We want to separate these We want to say the what and this is more like the how and for the same piece of information You might represent it two different ways depending on where you what your application is again If you if you go right into message land then you lose all of that and then we talked just a moment ago about the protocols When you say what what are the messages when the messages is the combination of the protocol and and the data payload There are a number of ways that modules interact and we've categorized those essentially like architecture patterns Some of them are analog some of them are digital Discretes some of them interact through a pubs publish and subscribe methodology where one source provides the information and a number of elements We'll we'll receive and and process those and some things are request response That is you know, please you know put your put your put your coffee cup down. Okay. I did put my coffee cup down Thank you. We're done. I don't want to say to the whole room put your coffee cup I just wanted him to do it. So that's not a publish and subscribe That's a command response and I get a just a just a no kidding. I got it Response then I know it's been done. So request response is very useful for things like management Publish and subscribe is very useful for data dissemination like a track Track information is going to be useful for a number of modules within the social sensor We're not hard-wiring. You notice the diagram I had didn't have direct lines between things because you might instantiate things different ways and the idea is to make it As flexible as possible but have these well-defined interfaces. So certain information is going to be under Publish and subscribe, you know certain things like a lot again management functions are event notification a failure Or or a radar warning receiver Wants to get the word out. So IQ Signaling pre digitization Analog feed from from a IR sensor is another one So the question was asked what give me an example of an analog distribution. I should have repeated the question So our Data model was divided up into two pieces the management entities and the mission entities The management entities have to do with things like faults the mission energies have to do with data detection and collect information collection System management is a complicated beast Sensor management is the bigger picture sensor management is all of the things that the sensor has to do in order to do the job of a sensor and So the host platform communicates to the host platform interface and again We don't want to tie that to any particular host platform. The Navy uses different things than OMS for example host platform interface sends things like Health and status information back and forth to the system manager Which communicates with the hardware elements and the modules the task manager gets the tasking information look over there Do that thing collect this data report, you know, give me give me the answer to my question and the task manager also speaks to the modules and also there's a there's a Interaction between them one very important aspect of the task manager's job is resource management Task manager has to especially in a multi-end situation, but even in a typical radar situation the task manager handles mode selection or Request from the the host platform for a particular radar mode or EW technique There are a set of services that operate within the manager We're not defining how they're going to be we just say that there has to be something there that receives Information and we have a sort of client service relationship to find both up above and then from the managers down to the individual modules Which I don't show I do there we go. I want to move a little more quickly because of I'm looking at the clock The hardware sorry the software environment is at this point somewhat in a state of flux and we're hoping that this week We can get things nailed down It has been decided that we're going to match what the face consortium is defined as the interfaces between the operating system segment How many of you guys are familiar with face technical standard just one two three, okay? So we're taking pieces from face We are now Addressing how we're going to interact between modules in one of the candidates to that is some instantiation or a light version of the face transport services transport services segment and face is extremely complicated partly due to the very very complicated nature of the face data model and so What we're we're talking about that has not yet been decided is whether a light instantiation light version of transport services So it does some of the same functionality and allows you to use you know DDS or corba or whatever your sockets as the means But it abstracts that away But we're not we've we're defining units. That's one of the big differences between what we're doing and what they didn't face We are we are using SI units and we're defining them in in the in the logical data model I'm going to skip that because it's just too many words. Let's talk about the hardware Hardware They've been working at this sort of chassis level or box level and they a lot of work in the hardware working group has been to harmonize with Vita CMOS and host and also to define slot profiles and You know what slot profiles effectively do is say this pin is going to be used for this purpose when it plugs into the backplane And that is tremendously valuable and then with a standard like ours even though the module itself isn't defined by the single board computer for example Customer it wants to be able to upgrade to newer generations of single board computers They want to be able to acquire one that they know is going to be a one-for-one replacement Maybe better faster smarter, but but speaks the same way to the backplane as the old one And so a huge amount of work has gone into doing that There there are a number of you know, there there's a lot of work going on into defining the interaction between the plug-in cards a Lot of adoption of Vita host and CMOS For a while their power was a question now. They've settled on 12 volts or 3.3 volt ox and and the backplanes themselves are going to be 3u and 6u and there's a whole catalog of Plug-in card profiles for those That enable a system to be upgraded reconfigured in the field Specifically because of the compatibility and portability afforded by the plug-in profiles electrical mechanical working group is Focusing on connectors and mechanical interfaces They began with this taxonomy of Mechanical cabling and environmental specs they they have identified a whole raft of of approved connectors They started out using the spies standard spies as a navy standard for turreted EOIR sensors and have Expanded on that to include all of the features you would need regardless of the sensor type add connectors sped things up with high speed and ethernet and so forth and and and and this is outside my field of expertise, but Essentially every connector what it's for what it would how it would be used to standardize the mechanical and electrical aspects of things So that you can build up a sosa sensor so that you can have an aperture out front and Processing in back and the connection between them being standardized in such a way that you can replace that sensor at this the sensor head in front with a different one and still have the compatibility with everything that's interior and aft all Of this gets rolled together in the sosa technical standard and we have As you heard snapshot 2 has been published snapshot 3 pens down in just a few weeks The way it's structured is there's an overview material And what is actually a definition of the standard the standard itself with requisite shelves And then a set of appendices that have lots and lots of tabular information and and all the details of slot profiles and so forth And I strongly encourage you to read the front material and the technical standard It'll it'll amplify a lot of what we've talked about in here. I can't say that's exciting reading It's not that it contains everything you need to know a Little bit about the business process the business model for for the face for faces Sorry for sosa Hasn't been hasn't been completely worked out It is a work in progress in the business working group needs help. So those of you raised your hand earlier, please help One aspect of the business model is that if you are a if you're under contract to build something using the sosa technical standard You are expected to If you identify any flaws gaps is to report back to the consortium What you found we want this to be a living growing thing We do not want this to be static. We want it to be able to keep up with technology And the way people ring out these issues are when they actually use them. We know it's not perfect It's made by humans humans are not perfect. So part of the business model is to Advance it through through the acquisition process And that just goes into a little more detail Taking a page from the face verification process If you say my module, I think this is sosa, this is going to be conformant to sosa You need to be able to verify that yourself You need to then take it to a verification authority who then does a run for the record And if they actually do then the certification authority then can put that you know Wi-Fi sticker on it Or in this case the sosa sticker on it And then that could be put in a registry optionally So others know that you are selling a widget that has the sosa seal of approval You saw when you did your registration the little trifold that's a little handout that describes what we're doing here We have an outreach organization that that is helping to get the word out Although it seems to be getting out pretty much on its own at this point Okay, so Let's talk about how we actually operate in the consortium Now by now you've all onboarded You probably all signed up to be part of a working group subcommittee or something So a couple of things that I really want you to do if you have a video camera attached to your computer Please unplug it before you start it because WebEx really really wants to put your picture up there And what you get is a black square and everyone will have to deal with a black square So disconnect it because we're not doing pic cameras Secondly, and I'm going to make I wish I could just make this flash Log on to your computer first. You say well, why would that matter? When you log into the computer It tells you how to dial in when you dial in and you put your your Participant ID number in there It associates your phone number With your login So have you guys been in conferences where it's like who's speaking whose voice is it? Well, you don't get that if you do it right and that is this computer when you're talking your name will appear I don't know if we this is I don't think anyone was talking at the time But you'll see sound waves or they're different ways it represents depending on what mode you're in who's speaking So you never have to ask who's talking We get and we have to take attendance because we have to have a record of who participated If you dial in before you log in then you show up as call-in user and We're in is some number between a one and a thousand or something and then they have to go Who's call-in user three somebody talk who didn't you know do it right and now we'll you don't want to do that You want to access it from your computer first? So the the beauty of the WebEx thing is When you're in the conference you have I There's typically somebody is presenting material. It's either canned or live and There's a chat that you can have to provide supplemental information and that turns out to be very useful But the beauty of this is it's full contact. It works very well I will say though if you're using the internal speakers on your computer and you're taking notes Please mute your speaker because what happens to your speaker your microphone, especially a laptop is typically in the case So you hear And because you know who's talking everybody knows you're the one who's typing so you really want to mute Okay The other major tool we're using is this thing called play-toe. How many of you guys have tried play-toe? Okay, it's a web-based system. I'm going to just walk you through a couple of the features Over here on the left are the organizational entities Listed and if you select one of them you will the whole rest of the screen will be oriented towards that organizational entity So member level stuff Here steering committee architecture working group electrical mechanical working group, etc We're not seeing it right now, but you'll originally come up to the home screen I'll show you the home screen on the next slide the place. You're going to do most of your Sosifying I know I can't use that term, but I had to slip that in there. You can bleep that out Is is the documents tab because so this is a reverse chronological list of the documents in this area Certain ones are you see the little push pin there Certain ones are bleeped out or I'm sorry our peg to the top The AV to for example is here Okay, and so there certain things like the AV to you want to stay at the top of the list You want it to be accessible all the time so you can so you make it sticky So to look for something from a face-to-face from three years ago You're gonna have to scroll way way down The same yes, yes this defines everything else and so and and searches are unfortunately only within Within a particular view which is a little unfortunate this little plus guy here means that there's multiple versions of that So this is the AV to every time we update it We make sure that we keep the historical record of the past instantiations of the terminology I already mentioned the the the thumbtack The home home page looks like this so in other words the the first tab looks like this And there are a couple of things that matter one is there's a calendar and each one of these little dots is Actually a link to that particular meeting on that day and by mousing over you can see which okay This is the hardware working group meeting you can click that and go to the page for that And then you can use that to join the hardware working group Meeting on that date a record of all of the emails that go to the to the distribution lists are here So this one you're only showing three, but there's a something I can't see it But there's a you know button there that brings you a page you get the whole history all of our our official Correspondence is documented and if you miss something you can always find it there There are certain areas here that a little more special Temporary documents now. What is that for a lot of stuff? We'd really rather not email around some of these things are sensitive But you don't want to put it on the archive and have it there forever. So instead of Emailing it or doing something tricky what you do is you can put it into temporary documents And then I'll send you a message saying here Here's the link to the temporary document you pull it off and then let me know when you have it And I'll clean it up. So that's that's a repository that allows us to share it are sensitive material Now those other two on there that are labeled distro D no more Play-doh was authorized for itar, but actually wasn't authorized for distribution D So all of that stuff is moving to the the VDL and I'll show you that in a minute So I don't know the official date for when this is all going away But everyone should be getting a VDL account and I believe that's part of the onboarding material now Yeah I Probably a day because what happens is that request gets sent to a whole bunch of people I Don't know I get those requests, but I've never actually Done that stuff. I just got I got added to the privileged user list I get those requests, but Ilya is the one who's been clicking the okay list When talking about VDL in a minute, I just want to show you a number of things That are kind of in that required reading list Things like the social architecture principles, which are now in the snapshot the CV one Those show up on the social members page And certain things like the quality attributes the system view one And and the service view for have the also a home Here I may take this out of this presentation because now I basically say read the first five sections of the snapshot And and that's probably the best thing to do document review So in a few weeks you're going to get some information that says hey, there's a document there that you probably ought to review How do you do that? So there's a tab that says review documents not documents, but review documents when you hit that tab There's a click here to display review document when you click that little guy right there It brings you out to a window that shows The text in a really kind of weird way where there are these little bracketed numbers in the next every paragraph in a bracketed number Is a little quill little quill pen That's how you comment My personal preference is to grab the word version of the file Mark it up myself and then have that open on one screen and on the other screen go in there And then replicate my markings in here because it's you lose some formatting and some other things when it's represented this way, but what you do is is You you click on one of those quill pens and then you have to fill in Information and the information you have to say is automatically fills in who it is But you say what do you want to do like this paragraph? You know phrases reads like bullets, so change it to actual bullets That's what this person this person's comment was now. This is a editorial comment. You can have technical comments And you have to indicate something about severity Don't use the most severe form because that basically means it's the nuclear option. That is If you don't do what I say, you know my organization is to take its marbles and go home That's kind of what that is you you know, so nothing ends up being critical unless it's like huge But that's the process you're going to use to provide input to documents and we use this very very effectively all the time Now about the VDL How many you have VDL before who else you do? Okay, so you know that and I you know You'll have my programs at the top and they're my programs at the bottom and You click in there and it'll take you to a page. This is the initial page. You'll get to for Sosa It's the main page. There's a whole lot of stuff here. Please ignore why because The the the UDRI helpers that were helping set it up started doing the wiki. Well, we're not using it for a wiki It the VDL is strictly for Distro D documentation. So go to the shared file area ignore that stuff When you get to the shared file area, you're going to see something. It looks like you know traditional folder system And you double-click on any one of these you go in you can dig around deeper and deeper It's a fairly intuitive interface You know for example yesterday this this I forgot what this had but I Got changed a scratch drive and then I appended temp storage will be deleted. Don't put anything here This was where the original zip files that they used to move things over from Play-Doh went But all members hardware working group radar. This is the radar subcommittee and the security subcommittee All right now have distro D content. So it's on the VDL. Everything else lives on Play-Doh Okay So I Hope you found this informative. I do want to emphasize that this is a modular open systems architecture We're trying to do top-down. We're following the gray box concept. It's very very important Our success in this effort depends on everyone's engagement there are a lot of people who will dial into meetings and That's it. Please don't be like that Participate constructively Volunteer to help out if everyone volunteered just a little bit. We would be able to move that much faster So I strongly encourage you to you know just dive in It's interesting and don't be afraid to ask questions