Greg Rocco, Member Technical Staff, MIT Lincoln Laboratory
Greg Rocco is a Technical Staff member at MIT Lincoln Laboratory (MIT-LL), where he started back in 1977, doing both board-level and ASIC designs for signal processing subsystems.
In 1994, Greg joined what is now Mercury Systems as a pre-sales consulting system engineer. At Mercury, he gathered requirements, conceived and architected new product concepts and ushered them through engineering. Greg became very involved with standards work as the lead editor of OpenVPX and editor of VITA 75.0, 75.11, 75.20, 75.22 and 62.0.
When Greg returned to MIT-LL in 2012, he started representing the interests of his sponsors in the standardization process and the COTS ecosystem. He created the OpenVPX tutorial, and started proposing content to OpenVPX. He is editor of OpenVPX, was editor of ANSI/VITA 46.0-2019, participates in several other VITA Working Groups, and participates in the development of the CMOSS, HOST and SOSA standards.
WORK WITH VITA
1. As editor of VITA 65 (Open VPX), what are some of the most interesting ways you have seen companies work together towards a common standard?
We do pretty well at ‘coopetition’ within VITA Working Groups; we understand that many of the members are competitors, but we manage to cooperate. In my current role, I have the advantage of not being affiliated with those competing to make products adhering to the standards. It’s really important to make sure that each person with a view has a chance to be heard. If I feel that someone’s idea is not practical, I try to lead a discussion, asking questions, with the goal being they either convince me to go their way or I help them figure out that what they’re proposing may not be the way we should go. It’s important to be open to changing your mind, based on new arguments.
2. What is your secret to managing all of the diverse inputs you receive?
In order to manage all the input we receive, while reviewing drafts of standards, we maintain comment spreadsheets. This is an important tool in helping us stay organized -- making sure that a comment does not get missed and giving us an audit trail in the event that we need to go back and review how we got to where we are. We can sort comments by section or line numbers enabling us to merge spreadsheets from multiple reviewers and can identify when there are multiple comments associated with the same area of the draft.
WHY ENGINEERING?
1. Did you always want to be an engineer? If so, why? If not, how’d you wind up here?
I think I knew I wanted to be an engineer before I knew the word for it. I have memories of wiring up batteries to lights and switches when I was in the first few years of grade school. By junior high and the beginning of high-school, I was building Heath Kits of things like a vacuum tube volt meeting, short wave radio, oscilloscope, television, etc.
I became interested in amateur radio, but was a very shy kid. I preferred to let someone else do the talking. Before I invested in amateur radio equipment, I went to 11th grade at a high school with a radio station and I became chief engineer. I was also chief engineer of my college radio station. Around this time, I also got access to minicomputers and learned how to program.
2. What has surprised you the most about the work you do with embedded computing?
Our ability to go at higher and higher data rates over copper backplanes.
3. What is one of the biggest issue currently facing engineers?
Sometimes not being listened to by upper management. One of the mantras I learned in college that has stuck with me is “the sooner you fix a problem, the cheaper it is to fix”. When engineers see a problem, particularly when a system is safety critical, it is import that they be heard.
4. What advice would you give to someone looking into this field of engineering?
When considering a job, look at what sorts of things you will actually be doing during your work day; think about whether they are things you want to do. There are many different kinds of engineering jobs, so think about what you like doing. I like interacting with other engineers and leveraging my experience to help create standards. Hence, for where I am at now, working on standards is a good fit.
Off the cuff: How do you stay sane with all the standards discussions activities in which you participate?
It's important to be really organized, pay attention to details and keep good notes. As I am using standards, I keep a list for each standard and of problems I have come across. When the standard is being updated, I pass the issues on to the rest of the Working Group for the standard in question. I set up reminders on my computer to nag me concerning things that need to be done, like which ballots are open and when they will close.
I generate indexes of my notes by subject and contact. I also have good tools for searching emails and files. As I mentioned earlier, we use spreadsheets to keep track of the status/resolution of comments to a draft of a standard.
