To the layman, engineering can seem like a mysterious world of coding and hardware – we get it.
That’s why we sat down with some engineers about the detailed yet exciting process involved when they begin designing satellite routers and the software to support them.
With this blog post, we hope to provide a glimpse into the mystery surrounding the engineering world by getting to know two key engineers at iDirect Government: Director of Software and Architecture Adrian Robinson, and Hardware Development Manager Tim Hoyt.
These are their stories.
So, how does the engineering department work?
Adrian Robinson: Typically, things start with product management. They are the ones who define what we should be working on like new products that we need and new features. Product management meets with customers or others in the field to figure out what would be a good next product for us to work on. Then that comes over to our architecture team to then try and convert that into engineering documents to help the team understand what we’re trying to accomplish and where we’re going.
There’s a back and forth element at play here, because there may be things that might be a little too much. The healthy back and forth helps us figure out what we can and can’t do with the current technologies that are available. From there, the engineering teams will work with architecture to actually build the plans to actually make the new products and go from there.
The best way I can describe it is, it’s kind of like a car. A customer may say, “I want a red car,” but there’s all kinds of decisions to be made. Does it have four wheels, two wheels or six wheels? What kind of engine is in there? How many seats or people can it hold? There’s a lot of details that need to be worked out, and that’s what architecture does with product management. Together, they establish what all those details are so they can take the general requirements and work to refine them so we have a complete definition of what the customer wants before we (engineering team) take over.
How do the hardware and software sides work together?
Tim Hoyt: Architecture draws the line and says, “This is what’s going to be implemented in hardware, this stuff is implemented in software.” Then we define an Application Program Interface (API), like a documented interface, so we know how to talk to each other, and from there we generally work on one piece at a time. As we work, we take into account the best way to move things around and communicate more efficiently. For example, we may move one thing into hardware and another into software if those things perform better when arranged like that, or maybe we find a better way to save power by switching one element from software to hardware or vice-versa. Usually, that stuff is defined up-front in architecture, but we may discover things along the way, so it’s kind of a fluid process.
Robinson: There’s a lot of trade-offs for performance or ease of use. A lot of times things in software are more flexible, so if we implement it in software, that gives the user ability to upgrade things in the field, whereas if it’s in hardware, it’s a fixed element and you can’t necessarily make those changes, but the hardware might be higher performing than if you did it all in software, so that’s the balance that we have to think through every time we have a new product.
But the process is the same, and really, we never do anything in isolation. We can’t really sell just hardware because it doesn’t work without software, and we can’t sell software because it doesn’t work without the hardware to run on, so really it’s a total product where everything has to work together. If we have a software feature, but we don’t have sufficient resources in the hardware or if it’s not fast enough or have enough memory or the range of RF parameters that we need, we can’t implement that feature. So, sometimes there will be a software feature that drives requirements for the hardware.
Do you enjoy breaking things when you’re testing?
Hoyt: That’s how we know it’s going to work. If we can break it, we can figure out where it breaks and tell people not to do that. Especially for defense customers, it’s very important to push our products as far as they can go, because our customers are going to be doing much worse things to them.
Robinson: On the environmental side, for example, we dropped our 9050 OM and put it in water and shook it and baked it and did all sorts of fun and creative tests to it to make sure that anything our customers do to it out in the wild, we’ve already done, and we know it’s going to work under those conditions.
Hoyt: We try to do more to it than what’s going to happen to it out in the field.
Robinson: Within reason. I don’t know about running the 9050 OM over with a tank, but carrying it out of the back of a car and accidentally dropping it onto the concrete, that’s something we do test for and are confident that it will withstand that type of condition.
What’s your favorite test?
Robinson: Breaking the hardware is more entertaining (than breaking software).
Hoyt: The overvoltage tests are interesting, because it sparks and smokes when everything happens. The temperature ones are fun, too, and the drops are cool.
Have you ever had a test go bad?
Robinson: Oh yeah, I’d say particularly the ones that go bad frequently are the vibration tests. You put the product on this table where they’re shaken for hours in all different ways. Sometimes we haven’t bolted them down good enough and things start to come apart in the chamber, so those can be pretty entertaining.
What do you find about your job that is most challenging?
Hoyt: Trying to actually nail down a requirement. We – product management and everybody – want it to be 10 times as fast and one-tenth of size, weight, and power. In reality, we can maybe do half of that. Then there’s the back and forth. We have to figure out how to make the product almost what you want and figure out what things we can pull back on. Trying to nail down those things is a little challenging, because everyone wants a big, fast, awesome piece of hardware, but you also don’t want someone to carry 30 batteries with them.
Robinson: Everything has trade-offs. It’s always fluid and hard to know if you’re doing the right thing. With every product it’s a little bit of a guess. You’re trying to look into your crystal ball and foresee what people will want. Do they prefer to have faster products, or is a lower power requirement what they want?
Hoyt: It’s like, what will they want in five years? What products will be available in five years, what satellites are going to be up there in five years?
Robinson: So there’s that guesswork, and I would say for me, the other one is – in engineering – there’s always more work to be done than we have resources for. So it’s kind of the same problem, trying to figure out what we should focus on, which products do we work on, what features do we work on, what things do we put our limited resources on. And again, which one is going to be the most beneficial for the company? We could spend three years working on something that nobody wants, and that would be something we wish we could’ve figured out earlier.
What do you find most rewarding?
Robinson: For me, it’s when people actually take our products and use them in the field, or you talk to end users who have made use of them. Most recently, we’ve gotten a lot of feedback both from our sales engineers and our customers that the TRANSEC usability enhancements we made with Evolution 4.2 were very much appreciated and made things a whole lot easier. That’s a good feeling when you get that validation after putting in all the time and energy into something people appreciate and use. You actually get some feedback that confirms we made the right decisions, and it made somebody’s life better. That’s one of the most rewarding things about our job.
Hoyt: Yeah, I like going to the tradeshows when you actually see the end use, because all we ever see is the raw board. I know it works, and you can plug things into it and it does its job, but when you see how the integrators actually use it, it’s like a whole other level of customization.
You could probably work at any SATCOM-related company, but why do you work at iDirect Government?
Hoyt: I think we have a really talented team, but it’s also the dynamic. I think we get along really well, despite the fact that we argue all the time, and we do a lot with really limited resources, so that’s pretty unique. It’s also the culture and the way our management says, “Here’s your high-level requirements, go and make it happen.” It’s not like we get free reign and do whatever we want, but it’s a really dynamic development process. I left and went to a cyber security place, but there wasn’t the same interaction that we have here, and I missed that. So I came back.
Robinson: Yeah, I think one of our strengths compared to others is that here, we’re organized around a product rather than around a function. We don’t have the software engineers isolated by themselves and the FPGA guys by themselves and the hardware team by itself – everybody is working together on the same product. There’s always something new, so if you’re a software engineer you may not know a lot about the hardware, but you’re working with someone who does know, so you’re learning from each other all the time and that keeps it fresh and interesting.
We do have a lot of arguments, but they’re positive. It’s a positive environment, and we argue for the good of all. That’s one thing we take a lot of pride in. I’ve worked places where you can’t criticize anybody’s work without people taking offense to it, and then people see problems and they don’t say anything because it wouldn’t be well-received. Here, we’re like a family. We’re willing to say, “Hey, I don’t think that’s going to work,” and argue back and forth to find the best solution. Everything has trade-offs, nothing is perfect. Being able to have those exchanges and not have people get offended allows us to have those honest conversations. It makes a better product, and it makes the process more enjoyable because you’re not walking on eggshells worried about upsetting someone.
Hoyt: No one is going to be afraid to say that’s a bad idea, it doesn’t matter who. Someone who works for me can say, “Hey, that’s a bad idea,” and I can say, “Ok, tell me why. Let’s go to the whiteboard and figure it out. What should we do?” I think it’s a great environment where someone who just started can point something out – it keeps us productive.
Robinson: When we’re interviewing people, we’re looking for different viewpoints because everyone has something to offer, even a guy fresh out of school. He may not be very experienced, but he may see something that someone who’s been here for five years has forgotten to even question anymore. That new guy can come in and say, “Why are you doing it that way?” and the answer a lot of the time is, “We’ve always done it that way.” That doesn’t mean it’s the right thing, it just means you’ve fallen into that trap. Having that diversity of viewpoints really helps challenge us all and keep things fresh.
Anything else you would like to add?
Hoyt: We have a good social environment. We celebrate our accomplishments no matter how small they are, and I think that’s important too. When you’re working on a two- to three-year development, you’ve got to be able to celebrate even when something minor happens.
Robinson: Yeah, because that customer feedback can be very long-coming. With the 9-Series, for example, we worked on that for two to three years, then it went out for certification and all that stuff, so it was five years before we got any feedback. That’s a long time to go before someone says, “Yeah, you did a good job,” or “Oh that’s terrible product.” Finding things along the way to get excited about and really celebrate and acknowledge the hard work everyone’s done is very important, and I think we do a good job of it.