About

Personal life basics…

My name is Chris Juszak and I live in Colorado with my wife Laurie and my son Lee. 

This website…

This website (geohub.com) is a convenient place for me to post notes for later reference. Every so often I clear everything off this website and start over (saving some of the old stuff that might be useful to me some day).

Work life basics…

My background includes engineering support for nationally distributed Department of Defense (DoD) test and training activities. I have a Master of Engineering degree in Systems Engineering (2014) and a Bachelor of Science degree in Computer Science (2000). I worked for the Naval Air Systems Command (NAVAIR) from 2002 to 2005 as a Computer Scientist (federal employee). NAVAIR gave me unique opportunities to learn about military range operations and contribute to nationally distributed military training operations. Leaving NAVAIR in 2005 was a decision to pursue new engineering opportunities. Since leaving NAVAIR, I have worked for four different defense contractors providing engineering support to the DoD, including Cubic, BAE Systems, Wyle Laboratories, and KBR. During my time with Cubic (2005 to 2007), I learned more about contracting, business development, government organization, and engineering team building. Leaving Cubic in 2007 was a decision to remain active on direct engineering tasks rather than the increasing supervisor and business development duties I was being tasked with at the time. I started working for BAE Systems in 2007 supporting Office of the Secretary of Defense (OSD) Test Resource Management Center (TRMC) contracts related to distributed software development and network infrastructure support. The Test & Evaluation (T&E) projects that I supported for BAE Systems involved a lot of the same technologies and people that I had worked for while supporting joint training events for NAVAIR. I started working for Wyle Laboratories in 2013, continuing to support TRMC projects when BAE Systems no longer had a contract vehicle related to these projects. In 2016 KBR purchased Wyle Laboratories and I became a KBR employee. While working for BAE Systems, Wyle Laboratories, and KBR, the primary contract vehicles I have supported have been through OSD’s TRMC, with tasking assigned to various projects throughout the DoD by TRMC. 

I realize the words “defense-industry contractor” can bring up visions of secret projects, government conspiracies, and various other things that media and entertainment have bashed into our brains over the years. Do not get too excited. I am just an engineer that has an interest in cool technologies and the DoD has a lot of neat toys and has been kind enough to give me a lot of opportunities. I could just as well be programming elevators or printer drivers (two of my most promising job prospects before I started working for NAVAIR). That said, I am still trying to figure out what I want to do when I grow up 🙂

The type of work I do has evolved a lot over the years, but involves a mix of systems and software engineering, working with distributed engineering teams, providing distributed software development related training, and various kinds of software support and troubleshooting. The contractor I work for now provides engineering support to organizations throughout the Department of Defense (DoD) and occasionally some non-DoD projects. So, what does that really mean? Well, I am a programmer that mostly uses C++, but I use a lot of other programming languages as well (e.g. C#, Java, Python, etc.). Really, I can confidently say that I can jump into any programming language and learn how to be proficient and productive using that language. To me, it is the underlying concepts that are important, and the language is just a tool that facilitate telling a computer what you want it to do. C++ has been my go-to language mainly because that is what the folks I work for mostly use. Any language I have never touched is just some time and reading away. These programming languages, operating systems, and technologies are all just tools in our toolbox. They will all fade away some day, but the basic concepts will still be there. 

Right now, I provide support for a specialized model driven distributed engineering architecture (which can be used with C++, C#, or Java). This capability does some cool things. For one, it allows engineers to model communication interfaces in a specialized data definition language. “Communication interfaces” refers to all the data that needs to be exchanged between systems in a distributed network environment. This could be within a single lab, or on a network that spans continents. Most of the projects I have supported are for systems within the continental US. So, part of my job is to sit down with engineers across the DoD, discuss the kinds of information that needs to be exchanged between systems, and figure out how to translate that information into a specialized format. This includes the structural composition of persistent and momentary data types as well as some behavioral aspects of how this data is exchanged.

Once we have modeled the kinds of information that needs to be exchanged (and some behavioral aspects), we end up with a data definition file, or multiple files in some cases (which look a lot like C++ with namespaces, classes, attributes, method signatures, etc.). These files are used by a centralized repository to autogenerate programming libraries with Application Programming Interfaces (API), example code, and other capabilities (e.g. a logging and replay system). This leads to the next part of my job. So far, modeling the communication behavior between systems has been a theoretical or academic exercise. The next step is training software engineers how to use the autogenerated APIs to integrate individual systems into a network distributed system. Other activities include working through issues, testing, troubleshooting, giving demos for specialized apps, etc. 

So, what kinds of systems are these? So far, what I have described is generic and could really be used for any network-based communication system in any industry. The DoD community (AKA defense industry) has taken this capability and agreed on certain “standard” ways of communicating between systems that support Test & Evaluation (T&E) and training. I like to divide this into two oversimplified categories: simulation and instrumentation – although the DoD’s term is “Live, Virtual, & Simulated” (LVC) data (which causes more headaches to explain than it is worth). Simulated data is the “made-up” stuff. This could be a simulated aircraft firing a simulated missile at another simulated aircraft. Since it is all “made up”, these entities can fly in their own little world, have their own concept of the terrain, and even operate in time that is slower or faster than real time. Instrumented data is the “real” stuff that is measured somehow. This could come from telemetry systems, radar systems, optical tracking systems, etc. The “LVC” thing basically has to do with how we can do meaningful things with made up data and measured data in the same “event” (e.g. for testing or training). There are places where this is possible, where it makes sense, and where it can add value to an event. There are other places where LVC integration is either impossible, nonsensical, exceedingly difficult, or poses safety risk. In any case, I also spend time explaining what these “standard” data types are to engineers, how to use them, and even how to leverage them in the composition of new custom data types (which can save a tremendous amount of development time, reduce overall program risk, etc.). 

So, I have either lost you at this point in a bunch of techno-jargon that you really do not care about, or you are following at least some of this and it sounds kind of cool (but is likely hard to envision). I have realized how easy it is to lose people’s attention over the years, giving many trainings and demonstrations. Luckily, we have cool 3D visualizations and graphical user interfaces (GUI) to keep these engineers’ attention that we train and support. I would have bored myself to death by now if I did not have cool visualization software to play with, or real projects of my own to work on. One cool project I worked on is a system that tracks live aircraft using something called ADS-B. ADS-B is used by aircraft to send all sorts of information, including identification, position, etc.. For some reason, data is more interesting if you know it is coming from live entities. So, I use this aircraft data and sometimes various things I have instrumented with GPS sensors, etc. in trainings and demos. Then I will use software that simulates other data types to demonstrate various concepts. Lately, I have been using a small radar interface simulator along with a 3D geographic visualization tool to show what it looks like when objects are being tracked by a radar. The radar itself can be controlled by other software, which helps demonstrate system monitoring and control concepts. I have also built other small applications that do things like fire simulated missiles at the planes and do all sorts of other things to help visualize geographic data modeling and behavioral concepts.  

A side effect of working with various organizations within the DoD is that I will spend a lot of time learning about how their systems work and working through all sorts of unique and interesting challenges. This gets me involved in other kinds of tasks as well. For example, I have worked with tactical communication protocols, network infrastructure and performance testing for distributed events, static code analysis, etc. 

My LinkedIn profile has some additional info about my work experience… Christopher Juszak | LinkedIn

I also dive into personal side projects occasionally to help keep my skills sharp (e.g. to work through a project in a new programming language, do some kind of electronics experiment, etc.). Sometimes I’ll post on this website with things that I might want to reference later.  

—  cj  —