A Trip To Reggio Di Calabria

This was a view from the conference’s break area — that’s the Mediterranean and Sicily in the distance.

I recently went to Reggio Di Calabria, a city in southern Italy, to present to present a paper I wrote at a workshop / conference. The trip was good, and (predictably, for Southern Italy in August) quite hot.

I spent an afternoon and evening in Rome before taking a train south to Reggio Calabria. While in Rome, I did a little bit of sightseeing and visited the National Gallery of Ancient Art, ate at some local cafes, and tried to nap away the jetlag. Once in Reggio Calabria, I:

  1. Learned about the custom of leaving hotel keys at the front desk;
  2. Tried, without success, to figure out if I actually could drink the tapwater: no one would say it was unsafe, but also everyone recommended just buying bottled water;
  3. Then tried, with some success, to figure out the meanings of the different types of bottled water, or at least “oligomineral” water;
  4. Visited the National Museum of Magna Graecia, which was way more impressive than I had even hoped for; and
  5. Was totally blown away by the horizon every time I looked at it. The Mediterranean with Sicily in the background consistently looked like a postcard.

The conference I was at also had an organized outing to the town of Scilla, where we walked through the fishing village / district Chianalea and climbed to the top of the ancient Castello Ruffo.

The only other notable event was getting my debit card skimmed at an ATM in Rome on my return trip, although I wouldn’t find out about that for a couple of weeks. Despite that, it was a great trip — I watched a number of really interesting talks, met great people, and of course the food (especially the gelato!) and scenery were just incredible.

Outdoors in Rome

National Gallery of Ancient Art

Reggio Di Calabria

Scilla, Italy

National Museum of Magna Graecia


A sign directing travelers in Rome’s Leonardo da Vinci to the international check-in

SAFE and Secure: Deeply Integrating Security in a New Hazard Analysis

One of my dissertation‘s main contributions was a new hazard analysis technique called the “Systematic Analysis of Faults and Errors” or SAFE. Hazard analysis techniques are, as I wrote about in 2014, structured ways of reasoning about and (typically) documenting the ways that things can go wrong in a given system. While traditionally these techniques have focused on safety problems — eg, a part breaking down, or a communication link becoming overloaded — there is a growing recognition that security should be considered as well.

That’s not to say that developers of safety-critical systems hadn’t previously considered security important (although in some frightening cases that was true) but rather that the degree to which safety and security problems can be discovered by the same analysis technique is an active area of investigation. I referenced the idea that this overlap could potentially be addressed by SAFE in the ‘Future Work’ section of my dissertation, and it fit in nicely with some work that was being done at the SEI. As a result, my PhD advisor, one of my committee members and I turned the results of that idea into a new paper that was recently accepted at the 4th International Workshop on Software Assurance (SAW).

The paper has three main ideas:

  1. It introduces a foundational, unified set of error/effect concepts based on Dolev and Yao’s seminal attacker model. These concepts are mapped to both the (network) security domain and the system safety domain, so we believe they can serve as the basis of any analysis technique that addresses the overlap of security and safety concerns.
  2. Their use is demonstrated in SAFE’s Activity 1, which considers how — irrespective of cause — a core set of error/effect concepts can be used to guide analysis of a component’s behavior when things go wrong.
  3. Attacker models (like Dolev and Yao’s) explicitly specify attacker capabilities. We demonstrate how SAFE’s Activity 2, which considers the effects of faults not caused by network-based stimuli, can use these attacker models to parameterize the analysis — making explicit assumptions about attacker/environmental actions that were previously implicit.

The workshop is in Reggio Calabria, Italy, so I’m headed over there at the end of August. I’m really looking forward to the trip, and the chance to talk about this work with other people working in the area.

I finished my PhD!

My dissertation defense (thanks to Dr. Bill Hsu for the photo)

On June 17, I successfully defended my doctoral research. Last week, I received final approval of my dissertation. It feels pretty weird to say it, but I now have a PhD, and am “Dr. Procter.”

I’m finding it hard to summarize the entirety of my grad school experience, so I won’t try. Rather, I’ll say that it was on the whole a very positive, enriching time and what I will miss the most are the people I met and spent time with while I was in Manhattan. I imagine that sounds sort of cheesy, but it’s true: most of the time I spent in my office reading papers or hammering out code or revising a draft has already started to blur together. Conversations with people — in the graduate school or at conferences or just out and about in Manhattan (or Lawrence or Kansas City, where I frequently found myself) remain quite vivid, though.

Another view of the defense (thanks to Dr. Bill Hsu for the photo)

In the big scheme of things, it of course hasn’t been very long: only a couple of months have passed since I was in front of everybody trying to explain what I’ve spent the last 4.5 years doing. I’ll write another post soon about what I’m up to now (preview: I got a job and moved east!), but for now, I’ll just say that while I’m happy to be done, I already finding myself missing a number of things about Manhattan (like Varsity Donuts!)

A trip to Delft

Delft and the Oude Kerk (Old Church) as viewed from Nieuwe Kerk (New Church)
Delft and the Oude Kerk (Old Church) as viewed from Nieuwe Kerk (New Church)

In July I wrote about a recent paper covering my lab’s recent work with a concept called “Error Type Refinement.” Then, in late September, I got to travel to the city of Delft in the Netherlands and present the work. I presented at the ASSURE workshop, which was co-located with this year’s SAFECOMP conference. The workshop and conference were great — the presentations were really interesting, and I got to meet a lot of people working in the field (many of whom I knew previously as names on papers that I had read!)

I also had a lot of fun exploring Delft — the city is very old, and has a lot of really cool history, including a couple of neat churches — the Nieuwe Kerk (or New Church, though construction actually started in 1396) and the Oude Kerk (or Old Church, which dates to 1246). I also got to see more modern buildings (like the University library, which is a giant cone built into a hillside) as well as very small ones at Madurodam, which is a theme park that has 1:25 scale replicas of famous Dutch buildings, roads, ships and trains.

It was really nice to have nearly everything in the city easily accessible by foot, though I felt like I was always at risk of getting run over by people on bicycles, which was quite a change coming from the US. The canals (and accompanying ducks and geese) around which the sidewalks and streets were laid out were also a very pleasant change from the more mundane Kansas.

All in all, it was a great trip, and I learned a lot — both about safety critical computing, and about the history of the Netherlands. You can check out the photos I took below!

Delft and its University

Nieuwe Kerk — Exterior

Nieuwe Kerk — Interior


Oude Kerk

Nieuwe Meer in Amsterdam

Error Type Refinement for Assurance of Families of Platform-Based Systems

The fault type hierarchy for timing related errors, extended first for MAP Apps in general, and then for the PCA Interlock App

Last time I wrote about my work, I mentioned that we were using the architectural modeling language AADL to describe a particular type of distributed, compositional medical applications called Medical Application Platform (MAP) apps. One neat aspect of AADL is that the core language — which describes hardware and software architectures — can be extended by language annexes to cover other, related aspects of a system like its behavior (via the creatively-named “Behavior Annex”) or failure-related aspects (via the “Error Modeling” annex or “EM”). The EM has a number of neat features, not the least of which is its error type system.

Briefly, the idea behind the EM is that you can describe problems with your system, like a sensor failing and producing values that are wrong, or a communications channel delaying or dropping a message. These problems, termed “errors” in the EM, are made machine-readable by being described in a type system. The EM allows errors to be related to one another by three refinement mechanisms: extension, renaming, and aggregation — so you can actually create a full type lattice, if you’d like. The EM even comes with a standard set of errors, called the error library.

In a new paper, we looked at using the refinement mechanisms in the context of MAPs to specialize these fault types first by a component’s architectural category — the idea being that there are a finite number of categories in a MAP system: things like software application, network controller, medical device, etc. — and then by a component’s actual implementation. Component implementations, of course, have very concrete faults, because we know the actual message types various components will be sending and receiving. The list of errors produced by this refinement can then help a developer when it comes time to perform a hazard analysis (like FTA, FMEA, or STPA), regardless of which analysis / style (ie, top-down or bottom-up) is being performed.

The paper was accepted to the upcoming ASSURE workshop in Delft, The Netherlands, (collocated with SAFECOMP) so I’ll be headed out there in September to give a talk on it. Hopefully we’ll get some good discussion from the other workshop attendees, plus it’ll be fun to check out the presentations at the main conference, not to mention the city of Delft itself.

A trip to Lübeck, Germany

The Lubeck town hall
The Lubeck town hall

My work with medical devices took me to Lausanne, Switzerland last month, and since I was already halfway around the world my advisor and I decided a trip up north to Lübeck, Germany to visit medical device manufacturer Dräger made sense. The work I did there was really cool — in contrast to the conference in Lausanne, where I was the only person talking about medical devices, the Dräger work focused on nothing else. Also, I had a little over an hour for my presentation instead of 12 minutes.

I really enjoyed meeting some people who work in medical device connectivity research at Dräger, and I hope that we can continue to interact in the future. I also really enjoyed exploring Lübeck, which, like Lausanne, had a number of neat historic buildings. Communicating with people was definitely easier in Germany than it was in Switzerland (with the exception of one very insistent fellow in a train station) so while there were still challenges — mostly related to getting around: the mass transit is impressive, but it’s also sort of difficult to understand at first — it was all in all pretty smooth.

I managed to grab another geocache in a really scenic downtown park, eat a ton of marzipan, and get (briefly) addicted to currywurst. I also went to a number of very cool churches, saw the famous city gate (“Holstentor”) and even walk through a puppet museum.  You can see some photos of the churches and outdoor areas below!

Lübeck’s Churches

Lübeck’s Old Town

A trip to Lausanne, Switzerland

Lausanne, as seen from the Sauvabelin Tower
Lausanne, as seen from the Sauvabelin Tower

I recently mentioned that a paper I wrote got accepted to MEMOCODE, a conference in Lausanne, Switzerland. Having never been out of the country before, a trip to Europe was really exciting. It was also a little imposing — I would be traveling alone to a place with no knowledge of the local language (in this case, French). Unlike my trip to DC, where I was most anxious about my presentation, for this trip I was actually more anxious about the typically unimportant details — getting from one place to another, ordering food, etc.

I won’t say that those anxieties didn’t turn out to be at least somewhat warranted, the trip was at times quite challenging.  At different times, I…

  • Accidentally ordered a dish served with a raw egg on top
  • Had to sprint through airports to make connections (in both Heathrow and O’Hare)
  • Had conversations entirely in French (thanks entirely to a phrasebook app on my phone)

But the benefits definitely outweighed the negatives.  The trip was an amazing experience, and the conference went really well — my presentation was unfortunately quite short (I was given only 12 minutes), but it went well and I got some good questions / discussion. I also really enjoyed seeing the sights in the area — the cathedral is amazing, as is the nearby Sauvabelin tower / park / forest (where I even found a geocache!).  On top of that, the food (particularly the fondue and the pasta) was delicious, and the local wines were also really good.

All that said, though, I’m happy to be home for a while, and back to business-as-usual.  You can check out the pictures I took below!


Lausanne Cathedral


Sauvabelin Park & Tower

An Architecturally-Integrated, Systems-Based Hazard Analysis for Medical Applications

An example STPA-style control loop, annotated with the subset of EMV2 and AADL properties from the paper
An example STPA-style control loop, annotated with the subset of EMV2 and AADL properties from the paper

A few months ago, I wrote about my recent work on defining a subset of the language AADL to specify the architecture of bits of software (apps) that would run on medical application platforms (MAPs). Since then, I’ve been working on how developers can use these semi-formal architectural descriptions to do useful things. The first “useful thing” is integrating hazard analysis annotations with these architectural descriptions — that is, specifying how things could go wrong in the app.

Structured hazard analyses have been performed for over half a century now (some dating back to the late 1940s!) but in some ways are still the same as they were back then, in that they are still unintegrated with the system under analysis — that is, any analysis performed would live in a separate document (often a Word file). In programming terms, this would be like having a system’s documentation be separate from the implementation, which isn’t nearly as useful as techniques like Doxygen or Javadoc, where everything is more tightly integrated.

So, after looking at a number of hazard analysis techniques, I (and others my research lab) settled on the relatively new, systems-focused Systems Theoretic Process Analysis (STPA).  From there, we looked at tailoring it to the medical application development process, and how that tailored process could be integrated with the architecture specifications from our previous work. The result of this effort was a paper, which was recently accepted to the 2014 ACM-IEEE International Conference on Formal Methods and Models for System Design (MEMOCODE) in Lausanne, Switzerland. I’m really excited to go and present.

My advisor has described the paper as “incredibly dense” (I blame page limits.) so in the next few months I’ll be expanding it into a whitepaper that will hopefully be much clearer, and will be of use to our research partners in regulatory agencies.

Using a subset of AADL to define medical application architectures

Code Gen Vision
The driving vision behind the MDCF Architect: An app’s architecture is specified in AADL, translated to Java and XML skeletons, and then run on a compatible platform.

Late last year (October-ish) I began working on a way to specify the software architecture of applications (apps) that run on medical application platforms (MAPs).  The specification takes the form of a subset of the Architecture Analysis and Description Language (AADL) and some supporting tooling — namely a plugin for OSATE2 (an Eclipse distribution which supports the editing of AADL) that translates from AADL to runnable MAP (aka Java) code. This work, referred to as the “MDCF Architect,” is part of my research here at K-State, and in fact this task constitutes a large part of my research proficiency exam — the (oral) examination all KSU PhD students must complete in order to become PhD candidates.

The work reached some good milestones in April, culminating in a paper submission to the Software Engineering in Healthcare workshop at this year’s meeting of Foundations of Health Information Engineering and Systems. My paper was accepted, and in about a month I’ll get to go to Washington DC and give my first conference presentation — I’m pretty excited.

Working with AADL, Eclipse, and a host of supporting technologies necessary for sound software engineering (Jenkins for automated building, JUnit for testing, Maven for building, Sphinx for documentation, Pygments for code highlighting, Jacoco for code coverage) was pretty cool, and one of the main reasons I enjoy studying in the SAnToS lab at K-State: not only am I working on the science part of computer science, but the ideas we work on get translated into real-world, publicly distributed tools.  So, while it’s not exactly likely that anyone outside of academia would find this work super interesting (yet!), the project is open-source (under the EPL), and freely available.

A trip to New Orleans

The HIMSS Show Floor
The HIMSS show floor — this goes on for a mile.

As I mentioned in a previous post, I attended this years HIMMS (Healthcare Information and Management Systems Society) exhibition and conference.  I was there to help show / run our demo, and there was also time to do a little bit of exploring in New Orleans, which I hadn’t ever visited before.

The show itself was huge, by just about every metric.  There was nearly a million square feet of floorspace in the main exhibition hall, which was a mile long.  There were additional exhibition floors on other levels tailored to other areas (our booth, for example, was in the “Interoperability Showcase”).  I’m not sure of this year’s attendance, but in previous years there have been over 35,000 attendees — roughly half the size of Manhattan.

It was a productive conference though, as I got to meet with a large number of people, both within the research group, and external people who stopped by our booth / were interested in our work.  By far the most fun meeting I had was a man who, after I introduced myself, told me that he recognized my name from one of the papers I was listed as an author on.  That was really neat.  It’s odd, though — I know that networking / the interpersonal side of work is super important, but I never feel as productive doing something like HIMSS as I do just sitting down (either alone or in a group) and writing a bunch of code.  I suppose that an understanding of non-tangible productivity will come with experience.

Exploring New Orleans was also a lot of fun.  I had some time to walk around the French Quarter, which is a really cool, old area.  It has Bourbon Street, which one of my friends described as “Disney World for drunks.”  That’s a pretty accurate description, I think — I walked through it both at night and in the morning when they were cleaning all the streets / starting to open up some of the shops, and honestly preferred the latter.  There were a couple people in my group who were semi-knowledgeable about the history of the area, and getting to hear about all the the Spanish, French, and American bits of history was really interesting.

Jackson Square, New Orleans
A view of Jackson Square in New Orleans.

I’m not quite done traveling yet, as this weekend I’m headed to Dallas for the MLG Winter Championship.  I’ll be there with a group of people who work with Leaguepedia, and I actually have a press pass, so hopefully I’ll get to meet some players / see some cool, behind-the-scenes stuff.