My name has been submitted as a nominee for the next President of the International Council on Systems Engineering. INCOSE has asked me to create a position statement and submit a picture and bio for them to post on the website. I've included it here so that you, my readers, get first look!

The election begins in November and is open to all active INCOSE members as of October 1, 2012. Electronic and paper ballots will be sent out the first week of November and voting closes November 23rd.

From INCOSE: Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.

As I reflect on the INCOSE definition of Systems Engineering, I cannot help but focus on the “inter” element meaning “to cross.” Innovation only happens when you reach out and genuinely collaborate with a greater ecosystem.

So, let's focus on the core term interdisciplinary. The expectation of today's consumer (which can be a government, a person or an industry) is “more and more and more”. This places significant demands on the organizations creating these products to find the “next new thing, quickly – but at less impact to the environment, oh and cheaper....”. Increasingly we rely on software as the innovative element and use advanced materials and manufacturing techniques to quickly bring the product to market. The increase in software function brings even more complexity in the development processes and systems themselves – placing even more demands on the discipline of Systems Engineering and elevates the systems engineer role higher in the organization.

The demand on environmental safety and lower cost manufacturing challenges us to be open to new, innovative ways of doing business. To address these challenges, I believe that we as the Systems Engineering community must even more deeply understand the complete product lifecycle, from concept, through to development and production, and ultimately retirement and disposal. We must proactively expand our education, sphere of influence, and evolve and define the guiding principles alongside the product development processes themselves.

To achieve these goals, I will guide INCOSE to focus on these 3 core competencies:

Invest in our future through increased focus on youth outreach and university initiatives. Through my extensive work with youth, I have found that their passion, innovative out-of-the-box thinking and commitment to science and technology is contagious. They need a body like INCOSE to embrace them – and mentor them – while we learn from their modern views of where we need to be when they have our jobs. If we do not, we as an organization risk irrelevance to our next generation.

Expand our sphere of influence with an “inclusive community” approach. By this, I mean reaching out to the larger ecosystem of professionals who are stakeholders in the systems engineering and development process but may major in a specific expertise outside of our own (ie analyst relations, marketing, finance). The perception of SE must change to embrace the larger ecosystem.

Extend our reach into parallel industries experiencing systems engineering challenges. More and more, I see industries like medical devices, transportation, electronics and energy grappling with similar challenges as those who build missiles and airplanes. They have people performing systems engineering duties, but do not consider themselves systems engineers. They often do not have a set of standards or stakeholders with expertise with these issues. This presents a significant opportunity for INCOSE to provide value and guidance to a new population who desperately needs our expertise.

Finally, since INCOSE is a global organization, it must have a leader with global experience. I have held numerous positions with world-wide responsibility over the last 25 years – each requiring me to understand the cultural, business and technology challenges and spend time in the countries themselves. In my current role at IBM, I lead a large globally distributed team charged with the development of Systems Engineering Solutions for worldwide adoption including the products and industry best practices that you use every day: Rational DOORS, Rational Rhapsody, Rational Team Concert and Rational Quality Manager.

I have specifically visited and done business in the following countries to date:Asia Pacific: China, Australia, Hong Kong (both before and after unification), Indonesia, Korea, Japan, Singapore, Taiwan, Thailand

At IBM Greg leads both the strategy and development of Rational's product development platform, which is designed to address the needs of Systems Engineers and Embedded Software Developers based on industry best practices and leading products Rational DOORS, Rational Rhapsody, Rational Team Concert and Rational Quality Manager. Greg joined IBM through the Telelogic acquisition in 2008, where he served in several positions ranging from field engineer to sales executive to Vice President of Product Management over his 25 year history. Prior to joining Telelogic, Greg was with McDonnell-Douglas and then Honeywell Air Transport, where he led a software and systems team creating crew station displays for fighter aircraft and commercial jetliners.

Greg earned a Bachelor's of Science in Electrical Engineering (BSEE) from the University of Missouri and is an Association of International Product Marketing and Management (AIPMM) Certified Product Manager.

Greg is the IBM ambassador to INCOSE, representing over 400,000 employees, and is a member of the INCOSE Corporate Advisory Board. He currently is the INCOSE Associate Director for K-12 Youth Outreach and is creating a vibrant, fun presence at our Symposia for kids and attendees. Greg has served on a number of INCOSE technical committees ranging from Requirements to MBSE to Tool Interchange and is currently pursuing his ESEP certification. Greg also is a Board Member of the INCOSE Central AZ Chapter and was a key force in recruiting new leaders and re-founding the chapter in 2008. Under the new leadership, CAZC has also created one of the largest INCOSE Student Divisions in partnership with Arizona State University.

Outside of work and INCOSE, Greg is a father of 2 teenage boys and acts as Committee Chair and executive leader of Boy Scout Troop 301 in Mesa Arizona (and is an Eagle Scout himself) and mentors a championship FIRST Robotics team. He also is past President of the American Sand Association, a 20,000 member organization that advocates full access to public lands.

At IBM Rational, my team creates solutions for our customers who develop complex and safety critical systems. Many of us (me included) have worked in their shoes before coming to IBM so it gives us valuable insight and experience with the kinds of challenges they face.

Many of us "have a life" outside of work that include some fun hobbies so we can escape from the pressure of our jobs. But on the other hand, some may actually be related to our work! For example, I belong to a model train club called Maricopa Live Steamers. We are one of the largest private train clubs in the world. Before you think "oh, yeah, I had those little trains when I was a kid", take a look at the website. These are 'big kid' trains, ones so large you ride on them. Commonly called "inch-and-a-half scale", the distance between the rails is 7-1/2 inches and the engines and cars are between 5 and 7 feet long, making it about 1:8 scale. Some of the steam engines alone can cost their owners well into the six-figure price range!! We even host birthday parties at various locations around our park and provide free public rides on Sundays. Here's a live video feed, most activity of course is on the weekends.

We have over 16 miles of track across 160 acres of land, hundreds of switches, bridges, trestles, signals, crossings, miles of wire and pretty much anything a "real" commercial railroad has. In fact, some of our members are employed by or retired from various railroad companies across the US and bring valuable experience to the club.

One thing we pride ourselves on is the automated signaling system. Just like a real railroad, we need to operate safely, keep the trains separated, control traffic on single-track areas and allow the members to automatically select which of 5 major routes they wish to take. While we may not have trains running at 300 kph, we face similar risks - collisions, injuries and property damage - albeit on a lesser scale. We do carry public riders, so our insurance company insists on a proper safety program and signaling system (in effect, they are our regulatory agency!). Even at the relatively sedate "real speed" of 5 MPH (or about 40 MPH "scale speed"), the energy contained in the train (many thousands of pounds when we have our full load of 21 people aboard combined with the speed) can cause severe injuries if we have an accident. Our members certainly don't want to damage their equipment either, considering the expense of repairs and the fact that many of them spent thousands of hours painstakingly machining their engines out of raw materials.

We have developed a custom signal system with layers of safety built in. Out on the main part of the layout, we need to keep trains separated from each other and provide ways of sharing one-track areas where incoming (Eastbound) and outgoing (Westbound) trains must wait on sidings as traffic passes. We custom-make circuit boards, FPGA logic, and even the signal heads (LED's, with full aspect red/yellow/green signals). The signals work pretty much as you would guess, if you have a red light you must stop and wait. Yellow means the next signal ahead is red. Green is proceed. We detect trains by measuring voltage drop across the tracks, and it trips logic in the FPGA to control the signals appropriately. Each FPGA controls an area, usually called a "block". Some blocks are more complicated than others -- for example if they have switches, crossings or other complicated track configurations the logic can get quite tricky. Block controllers (we call them "CP's") communicate with each other as necessary to coordinate complex interactions.

In the main train yard, we use a computer to control the local area using USB through a complex set of relays, driver boards and digital communications chips of our own design. There are dozens of signals, automated switches, selection buttons and train sensors that are used to allow club members safe, easy access to the layout. When in the station, they can press a button to notify the computer they want to take a particular route. The computer then automatically configure the switches and ensures that there isn't any safety conflicts before giving them the green signal to go. Switch operation is quite unique: we bought a crate of low-cost cordless screwdrivers, removed the handle and battery, attached them to the switch hardware and send 300 mS digital pulses to them to align the switch to the desired setting. The system works the same way when trains are returning - the computer senses their arrival from a particular route (called a "subdivision" in railroad lingo), checks for safety interactions, aligns the switches and gives them proper signals for safe passage back to the station. Additional pushbuttons throughout the area allow train operators to command the computer to select different routes through the yard, select which track to arrive at the station (we have 5) or allow other movements as required to place their trains where they need to, all while maintaining safe operation and proper signalling.

The computer also lets us control the yard and station area manually (called "dispatching") during busy times, especially when we have our international meets. There are times when there can be over 50 trains operating on the layout at once! Safety is a priority during those times and we love the challenge of ensuring we get the trains out and back quickly and safely. We even have a certification program for dispatchers (I'm one!) and are learning proper radio communications techniques from one of our members who works as an Air Traffic Controller at Phoenix Sky Harbor International Airport! We have established radio procedures, operate a long range VHF communications system for us as well as a simpler and cheaper FRS-based system for our guests. This is another case where we essentially try to model ourselves after the 'real world' train systems as much as possible.

All of this complexity requires a layered, Systems Engineering approach. We have to ensure that each block is safe, then each collection of blocks, and then the entire system. We constantly must remain vigilant with the system, since our construction crew is constantly adding and modifying the track. Any change in the track configuration requires the signal crew to verify safe operation and make modifications to support their changes.

We on the signals team have a vision for the future (all it takes is time and money...) to be able to track train movements across our entire 160-acre layout. Of course running wires and sensors everywhere would be cost and technically challenging, so we are researching way of using advanced technology like RFID, GPS and ZigBee networks to see if we can come up with low-cost ways of sending location data back to the dispatch center. We would then use multiple, large displays of the entire layout (in this picture we only are tracking the local area near the station--which is complex enough!) Another goal is to be able to have these large displays visible over the Internet too, so anyone, anywhere can see the activity on the layout! Yet another System that needs good SE to be able to stay within our budget, be very reliable in the Arizona heat, and simple to operate by our members and guests. Once we have that established, then we could consider adding digital controls for switches out on the farthest reaches of the layout if we wanted! How much fun would that be?

Keeping all of this running safely is a fun way to spend a Saturday! Just don't tell my boss I'm "working"!!

Steve writes: "Japan already has a sophisticated alert system that notifies people by
SMS to their mobile telephones when the beginning of an earthquake is
sensed. But people don’t always respond with the urgency that’s
required."

This got me thinking. Based on anecdotal stories and video posted on YouTube, it hit me that there is another factor at work: that the victims simply didn't know *what* to do. Japan has a very fancy, automated earthquake alert system that tells you that something really bad happened but not what to do next.

Steve writes that IBM Research is working on simulations and ways to communicate to the general public the seriousness of the warnings -- simulations of what 'could happen'. I think that's great, so that they understand the warnings and take them seriously. What I'm concerned about are those who *want* to take them seriously but *can't*.

For example, in the YouTube video I linked to, it seems to me if the driver went straight instead of left that they would have immediately started going uphill. Instead s/he turned left and was caught in the flow of water & debris. Very interesting video, for sure.

What is needed is to not only warn that there "is a problem", but then to add "what to do about it". Given your GPS position, the type of danger, etc. then correct instructions could be sent to the phone. For example, in the tsunami situation it could have sent 2 kinds of instructions: if you are in a building, you must go to a floor at least XX meters above ground. If you are in a car, follow this routing to the evacuation route (or to a 'safe' building).

I can also imagine (and was discussed on the news) that visitors and ex-pats would be completely clueless if they are in an unfamiliar area. Even worse if you don't speak the local language. So - the system should be fully integrated to alert you of the danger in your native language, tell you what happened, what to do and where to go. Once the disaster is abated, you should then be able to register somewhere so others know of your status, locate emergency shelters & supplies, and generally find ways to survive. All this should be location based and in your language too...

I'm watching right now the most real of "reality TV". A local Phoenix TV station is live-streaming video from a sister station in Oklahoma City on their website. I was alerted by a Twitter message that there were tornado warnings in Oklahoma (ok, yes, I'm a weather geek). What strikes me is that they are using some incredible technology to save lives and provide up-to-the second data on exactly where a series of huge tornadoes are. A true system-of-systems that didn't exist 10 years ago (maybe even 5!). The engineer in me watches with intrigue and wonder about what's going on 'behind the scenes'.

I'm fascinated by both the intensity and urgency of Mother Nature, as well as the teaming of technology made possible by my fellow engineers and scientists. It's incredible the amount of information the TV meteorologist has at his fingertips that only a few years ago was nonexistent or unavailable. Graphics, radar, live video, audio, instant communications to millions of people.

The main weapon of defense today: live Doppler radar, in "velocity" mode, superimposed on a map of the Oklahoma City area. The radar is "smart"--it's automatically highlighting areas that are exhibiting the strong signature of a tornado. He's then drawing 'forecast' lines from there, and the system automatically calculates arrival times to various places of interest (mostly schools since they are usually well known in the areas affected). I am amazed at how he and his colleagues can quickly pan and zoom around the area, instantly pinpointing the path of these storms. It's also amazing in the fact that they are instantly reaching millions of people in real time, giving them valuable minutes to take cover. And it's not just one tornado -- right now they are calling out two, and tracking a couple more suspicious areas. Incredible. This radar is a 'system of systems' -- antennas, processors, transmitters, and data distribution systems that make sense of the electromagnetic reflections coming from these storms. What's even more amazing is the variety of modes he can take advantage of to analyze the storms and clearly identify the 'tell tale' signs of circulation.

When I was a child, I lived in an area like this. In most cases we never new a storm was coming until the sirens went off or a house exploded -- I am amazed how far this technology has advanced. Thankful too for the advance, even though there will most definitely be loss of life, the extra warning time (some of these places are getting 10 to 20 minutes!!) will assuredly save countless others.

They are also taking advantage of another 'system of systems' - the telecommunications network. They have some "storm chasers" out in the field, following the storms on the ground. They are communicating with the weather center in real time, with live video using the cellular data network and satellite communications. It's incredible the amount of information pouring into the weather center. All of this data is being interpreted, real time, by the broadcaster. The TV station then instantly transmits his voice to the population affected -- and even to me -- IN PHOENIX -- using another system-of-systems, the Internet.

Aha - finally found some time to type a quick blog entry here. Hi - my name is Greg Gorman and I'm on a team at Rational that is defining and managing a solution for Systems and Software Engineering. We have the ability to survey the entire Rational product portfolio, work with subject matter experts and our own experience, and define the products, practices and services that make up a solution that may benefit our customers and prospects. Sound like fun? I hope so, and look forward to your input.

A few weeks ago I gave the keynote address at one of our SE Symposium events in San Diego. I like to use as an example of how pervasive software has become in our society (and thus also how important good systems engineering is) by using a simple example -- just go to your favorite search engine and type in "software glitch blamed for" and let it rip.

You'll see some famous and not so famous headlines, and it's interesting to see what floats to the top. In some cases, it's truly a software failure. In many, I contend it's a systems engineering failure (an interface failed, bad data, bad response to environment, bad response to a failed component, etc..)

But -- what I wanted to lead out with was -- a big thank you to my colleagues in the SE and embedded development world: 40,000 flights did NOT crash todaymillions of train passengers world-wide got to where they supposed to go safelybillions of phone calls were completed properly and lasted as long as they were supposed to

Sometimes we forget that the hard work of men and women in engineering truly have accomplished amazing things and have truly made this a Smarter Planet!