Category Archives: Engineering

Interoperability

Before talking in-depth about data centricity, it makes sense to talk a bit about interoperability. For much more detail about interoperability and data modeling, I highly recommend this e-Learning video from rti.com.

To start with the basics, you have to understand your goal for interoperability between systems. I will use a modern car as an example of a system, and the future goal of connected cars as an example of a system of systems.

A system:  Performs some function. In the case of a car the functionality this includes:  Drive from point A to point B, use sensors to detect vehicle maintenance issues (e.g., low tire pressure), use sensors to help a human avoid crashes, etc.

A system of systems:  Multiple individual systems coordinating, and providing a greater whole. In this example, this includes multiple connected cars communicating to spread information about the driving conditions ahead to prevent accidents.

When you are building a system of systems, you have to take into account several non-functional requirements that affect how your systems behave. These functional requirements include:

  • Interchangeability: A system can be replaced, and the overall functionality of the system-of-systems remains the same
  • Replaceability: A system can be replaced, but may not provide the same capabilities as the original. The functionality of the system-of-systems will not be the same.
  • Extensibility:  A new system can be added, providing new capabilities
  • Integratability: A combination of systems can be composed into a functioning whole.

In the connected-car world, this means:

  • Interchangeability:  All cars provide the same functionality to the system-of-systems, including, for example, information about the driving conditions ahead.
  • Replaceability:  Some cars may provide less information, or different information about the driving conditions ahead. However, this information can still be used to help form a picture about upcoming hazards.
  • Extensibility:  Newer vehicles will provide additional information about driving conditions that were not available in older models. Some cars can use this new information; others cannot, but it will not harm the overall system-of-systems. It will evolve over time as more new vehicles can process this new information.
  • Integratability: Vehicles communicate in a way that is well-defined enough that algorithms can be added to individual systems or the system-of-systems that provide emergent behavior; vehicles cooperating in ways that prevent accidents, help traffic flow, etc.

To meet these non-functional requirements, you need to look at the levels of interoperability within your system-of-systems. These are well-defined in modeling and simulation theory.

Levels of interoperability

Levels of interoperability

I will focus for now on levels 0- 3:

Level 0:  No interoperability. That is the current level of interoperability between cars.

Level 1: Technical Interoperability. This means that there is some common protocol defined so bits can be shared unambiguously. The connected cars meetup I wrote about in my last post was describing how they were sure that defining the hardware and protocols to be used to communicate between cars would be enough for interoperability. This might be enough, if every car defines exactly the same set of messages – though defining this set of messages is a challenge that will require standards. This is because level 1 allows replaceability of components, but not integratability or interoperability.

Level 2: Syntactic Interoperability. This means that there is a common protocol, and there is a common structure or common data format for exchanging information. At this level, a data model is defined, and each system must send and receive data described by that model. By defining the data that are being communicated, it is possible to integrate vehicles that have different capabilities – as long as they provide the data described in the data model, they can be integrated into the greater system, and algorithms can act on that model to help cars drive more safely. This level of interoperability supports interchangeability and integrateabillty.

Level 3: Semantic Interoperability. This means that the data has a meaning that is explicitly modeled, and shared between systems. When data has a common, well-defined meaning, interoperability can be achieved. At this level, algorithms can easily be developed for vehicles regardless of which manufacturers’ cars are communicating.

If car manufacturers support interoperability levels 2 or 3, they (or third parties) can develop algorithms that can go beyond looking at road conditions, or sharing common sensor data, but will be able to help traffic flow, help prevent accidents and back ups, and make driving more fun.

My concern with the connected-car world is that they are barely thinking about level 1 interoperability – and at that level, with no data model, and no shared meaning of the data, many of the benefits of having cars that communicate will be lost.

Using tar on a VirtualBox shared drive

I set up my laptop using VirtualBox with several virtual machines.  The last time I set up a machine this way, I ended up with some VMs with large drives that I didn’t use, and I ran out of space on the host.  To avoid this on my new machine, I decided this time to keep my VMs as small as possible, and do all major work on shared drives.

So, I was running a build on the shared drive, when I hit this error:

Cannot utime: Operation not permitted

This error isn’t very helpful, but I was able to google around until I found out that this error can happen if you don’t have full ownership of the files you’re trying to tar.  The next step was to figure out why my user didn’t have full ownership of those files.

It seems that if you use the VirtualBox Guest Additions to share folders, you have no option to set any options for the mounted folder.  This means that all files are owned by root.  Most of the time this is not a problem, but tar was very unhappy with this.

You cannot edit the /etc/fstab file to mount the drive automatically, because the shared folder module is not loaded before the file is processed (see the VB forum link below). So, for the time being I have manually mounted the drive with options that give my user ownership over files:

sudo mount -t vboxsf -o uid=1000,gid=1000 <shared folder> <mount point>

According to the VirtualBox forums, it looks like you can add this line to the /etc/rc.local file to mount at startup.  As soon as I have to reboot I will try this.

“We Have Male Engineers, Too… “

My mom is a software engineer, I’m a software engineer, my sister is studying to be a software engineer.  The first video game I ever played was written for me by my mom and dad.  I grew up with computers, and I knew from a very young age I was going to be a software engineer.

But it was still a pretty telling moment when one of my fellow women-in-engineering jokingly told our customer that “we have male engineers, too.”  It’s hilarious, but it really shouldn’t be.

I grew up in Silicon Valley, which means that I had a number of advantages that other people didn’t have – such as having a computer and Internet access long before most people.  Now those technologies are ubiquitous, with tablets and phones bringing the technology into every home, but I don’t see that making a big difference in who becomes engineers.  Increasingly those technologies are created to make people the consumers of devices, instead of tinkerers.  Technology has become something to own, not something to understand.

The greater advantage that I had growing up here is the culture.  Before we had the culture of startups, IPOs, and get-rich-quick, we had the culture of smart people solving hard problems.  I grew up knowing that engineering can be interesting and fulfilling – and not just the domain of some group of socially-awkward men.  Many places do not have this culture – and without it, you don’t have women engineers, or engineers in general.

I had a struggle with culture shock when I moved to London.  Just one example is when a man flat out exited the conversation when I mentioned the words “space robots.”  It wasn’t because he was afraid of the concept, or really had anything much to say about it – he was just suddenly categorizing me as a nerd, and uninteresting.  In Silicon Valley, this elicits the exact opposite response, regardless of whether people are thinking of the Mars Rover or Skynet.

In the UK, a lot of engineering is categorized under the umbrella of IT, and I think this says something about the culture.  There’s a certain smugness that City types have when thinking about the nerds who do that infrastructure stuff.  It’s as though they control the big picture while their IT staff just provide some help to allow them to achieve their goals (i.e., get rich).

Some places I’ve worked are even more surprising – either in how they regard technology, or how they regard women in technology.   Some places were better than I expected, some worse.  But I know that we can do better, even here in Silicon Valley.  Women need to know that they can be engineers, that they can be good engineers, and that they can enjoy it.  It’s one way to shape the world that we are building for ourselves, instead of just consuming what others produce.