 Bingo! We're back, one o'clock rock. This is Think Tech. I'm Jay Fidel. We're going to do research in Minoa. We're going to talk about space mission operations at UH Minoa with Trevor Sorensen, Professor of Engineering, in the space flight lab there, which is like a joint venture of SOES, the School of Ocean Earth Science and Technology and the College of Education at UH Minoa. And wow, we've got them all together in the space flight lab. And he's working on a bunch of things we're going to find out today. Welcome to the show, Trevor. Thank you. It's great to be here. And I will just make one correction. It's the College of Engineering, not Education. Oh, sorry. I was so excited. College of Engineering, of course. Okay, so what is the space flight lab and what does it do exactly? Okay, the space flight lab was founded in 2007 between SOES and the College of Engineering. And the purpose is to develop satellites, launch and operate them, in particular, satellites that can be used to test new technologies and further the research interests of the university, and in particular, SOES. And so I joined HSFL in 2007, a few months after it started. Okay. So tell us about your training. How did you get involved in space, for one thing? Well, I'm from Australia and I went to high school in the 1960s and I got interested in rocketry. I built my own rockets out of steel, made my own propellant and everything. And I kept the scrapbook on all the early space flights, the Gemini and Apollo space flights. And I started a rocker club in high school. And so when I found out I had an opportunity to come to the United States after high school, I naturally wanted to do aerospace engineering. And at first, my first job out of college was as an aircraft structural engineer, which I did not like that much. But once I got into grad school, I was able to get into space. Space program's mission, Pioneer Venus, was my first one and I've been there ever since. You're really involved in this, I know. So you have a PhD in engineering. That's a rare degree, isn't it? And how many people take that degree? Well, when I got my bachelor's degree in aerospace engineering, and I had no real intention of going on and getting higher degrees, except maybe a master's part time. But that was in the early 70s, mid 70s, and I was not a U.S. citizen at the time. And there was a big slump in the aerospace industry. And the job I had, I got laid off after six months. And I really couldn't find another job, so I was sort of forced to go to grad school. And I'm glad that happened because then I went on and got my master's and doctor's degrees. Well, at some point along the way, you got involved in software and you're involved now in software for these space missions and satellites. And my big question I told you before we started, I don't have an answer yet, is what was the magic moment where you went from space engineering and aeronautics to software? Because that's a different ball game, isn't it? Yes and no. A lot of engineering uses software and programming. And probably the moment for me was just before I started my last year of high school in Australia, we had a one week math camp, I guess, at the University of Newcastle, which was the local university. What city was that? Newcastle, New South Wales, Australia. Oh, New South Wales, okay. It's about 100 miles north of Sydney on the East Coast. And while in that week they taught us the basics of FORTRAN programming and asked us the sort of the culmination of the week was to design or write a little program. And I wrote one to simulate the flight of one of my rockets. And I loved that. I mean it was great. And then when I got into university, as a, my bachelor's degree, there were opportunities to write programs, continued on into grad school. My doctoral dissertation was to develop computer programs to determine the wind profile on Venus from the descent trajectories of the Pioneer Venus probes. And so, and that was written in FORTRAN as well. And also when I was in grad school, for recreational reasons, I started designing my own Star Trek type game, which sort of eventually in the 80s grew into a business. I became the head of a company that published computer games. Ah, no kidding. And still today? Well, that particular enterprise started in 1983. In 1990, we became an affiliate label of electronic arts and sold hundreds of thousands of games, very popular. In 1990, there was a hostile takeover bit of my company and I found that once lawyers get involved, the fun goes out of it. You heard it here on Think Tank. And so I sold my shares of stock and got out of it. And a couple years later, the company folded. It was a good time to get out of it, didn't it? And I started up another company that was just to develop games, not actually publish them. And we had one game that was published before that company went defunct. And I basically haven't done any gaming until about three years ago. And one of my fans contacted me and wanted to do an Android version of one of my games. And so I agreed and it was two years ago that he completed and it's now available through the Play Store, Google Play Store. Really? What's the name of the game? It's called Starfleet Deluxe for the Android. And I can get that on my Android right now. It'll cost you $1.99, but you can get it. I'll do that. So, but you know, there's a relationship and I'd like to explore that with you between writing games about space and writing software that actually takes you into space. Yeah, and actually in 1980, after I got my doctor's degree, I got it in 79 through NASA Ames. My research was at NASA Ames. And in 1980, I went to the NASA Johnson Space Center and worked as a guidance and control engineer there. And I had several friends, one of which became an astronaut later, but engineering friends, we formed the company. And our primary goal was to write a space shuttle simulator game that was based on the actual way the space shuttle flew. And since that still had to be developed and my Starfleet game had already been written and would take a lot less time to bring to market, we did that first. And as it turns out, we never did finish the space shuttle simulator, but did a lot in the Starfleet and strategy games like that. And I was an assistant to the flight directors for the space shuttle, worked in mission control. And after I'd done that for a while, which involved a lot of paperwork and I felt like my talents weren't being used properly. And an opportunity came to be a task manager in the software engineering department in support of the space shuttle. So I took that job and worked on the Ascent Design System space vehicle design system or dynamic simulator, which the NASA used for designing their shuttle flights. And so I was able to do my space engineering, but also get very involved in software at the same time. My experience is with business software, so it's a lot different. And you're writing in much more sophisticated languages than before training, which I guess is still alive and C++. But what kinds of things can you do with your engineering and your software? What sort of functions does that all perform for a satellite or a space mission? Everything or some things? Well, you can start very at the beginning with design. And a lot of tools are now being developed that where before an engineer had to go in and do hand calculations or with a calculator or even using small computer programs to do certain parts. Designing the space? All aspects of it. The analysis design, the aerodynamics of propulsion, the mass and the attitude dynamics, everything like that. There have been programs starting to be developed that takes the burden off the engineer. You have tried and trued algorithms that are used and where you can do what ifs for the design and run it in simulated flights and things like that. So it's been a great aid for the design. But of course the actual operation of the spacecraft, in the oldest spacecraft nearly everything was done on the ground and there was not very limited intelligence on the spacecraft but with the more capable microprocessors, etc. More and more of the intelligence and analysis and everything that has to be done is being done on board. That's a benefit because it's right there. And you don't have to rely on communications in order to do the processing. Yeah, and it became particularly obvious with the deep space missions where you have such a large time lag. But even in Earth orbiting where the time lag isn't the problem, you still have problems with outages or you don't have coverage because the satellite's not going right over a ground station. And there are targets of opportunity that might be missed unless you can get an instant decision on the spacecraft. So it helps the people who are piloting the spacecraft make instant decisions as they go through their routine. But is the software we're talking about also navigational software where you're trying to get to a certain point like you see in all the science fiction and you need to find your trajectory in order to get there? Yes, all aspects of it have actually in the software now. That's the guidance navigation and control GNC portion that they call that. And more and more the spacecraft on board are being able to design their maneuvers. In the simple case, for a low Earth orbiting satellite or maybe a geosatellite, they want to stay at a particular altitude. And so the onboard computer, especially thanks to GPS, knows where it is and when it starts to wander out of where it's supposed to be it can program in the burns and commands necessary to boost it back to be in position. And that can be done without any contribution from the ground. That can be done autonomously as they call it. One other question before we go to a break and that is does software written for space satellites do? Does it have to be specially robust? Does it have to have backup systems? Does it have to have the ability to function even if parts of the platform or parts of the software aren't working properly? There's software in most engineering projects is often what they call the long pole and the tent. It's the part of an engineering project that is usually underestimated as to how long it's going to take and what the resources are. And no matter how thoroughly you test it there seems like there's always that one bug in there that gets away until it bites you when you least need it. And I worked on the manned space program, the space shuttle program and when there's human life involved it has to be very clean, robust software. And like the space shuttle had five onboard computers. Of course when I was there they were pretty primitive computers and small compared to what it is now. The idea was to have redundancy. Yeah and they would have four of them were identical with each other and then they had a backup that was written in a different language and by a different company. IBM did the first, the main four. But if there was a problem inherent to either the language or the algorithms that they used it would not affect the backup. The backup didn't have the capabilities of the primaries but it had enough for survival and to be able to get the shuttle back down if necessary. And they also had voting capability. The primaries would vote, they'd each calculate something and if one of them disagreed it was thrown out. And so that was one way to ensure that a fault, an electronic fault in one of the computers didn't cause a problem. That's fabulous, voting computers. We could use that next Tuesday in election day especially this year. That's Trevor Sorenson. He's a director of, excuse me, a doctor of engineering in the Hawaii Space Flight Lab which is a partnership of the SOEST organization, the School of Ocean Earth Science and Technology and the College of Engineering at UH Manoa. We'll be right back with more about what he's doing. You're watching Think Tech Hawaii, 25 talk shows by 25 dedicated hosts every week helping us to explore and understand the issues and events in and affecting our state. Great content for Hawaii from Think Tech. Aloha, my name is Danelia, D-A-N-E-L-I-A. And I'm the other half of the duo, John Newman. We are the co-host of Keys to Success which is live on Think Tech live streaming network series weekly on Thursdays at 11 a.m. Aloha. Aloha. I'm Ethan Allen, host of likeable science here on Think Tech Hawaii. Every Friday afternoon at 2 p.m. you'll have a chance to come and listen and learn from scientists around the world. Scientists who talk about their work in meaningful, easy to understand ways. And you'll come to appreciate science as a wonderful way of thinking, way of knowing about the world. You'll learn interesting facts, interesting ideas. You'll be stimulated to think more. Please come join us every Friday afternoon at 2 p.m. here on Think Tech Hawaii for a likeable science with me, your host, Ethan Allen. Okay, we're back. We're live with Trevor Sorensen. He's a doctor of engineering at the space flight lab at UH Mandoa. We're talking about the software that he's been developing for various space flights. And I wanted to ask him to continue that for a moment. You were talking about redundancy in the case of space flights involving human life. And one system is on, what, five separate computers? But what else has done for that? And how does that differ when human life is not involved? All the spacecraft that are launched, we're the exception of the very small CubeSats, which are about that big. But most satellites that are launched is an investment of millions, in some case, billions of dollars, even if there is not human life involved, there is still a need for a very reliable system that provides mission success. Otherwise, years of work and resources go down the drain. And so one of the problems that satellites and spacecraft face is radiation in space. And the more expensive spacecraft have specially rad-hardened, there's radiation-hardened parts that they use that are resistant to radiation. You will also get shielding, generally aluminum shielding, that they'll put around critical electronics to block a lot of the radiation. Radiation can mess up a computer. Yes, definitely. And some of it is temporary. It'll just flip a bit or something like that. There are methods where they can scrub the, like a hard drive to determine if there is something like that has happened. But there are times when the radiation can affect one of the logic gates or something permanently. And you have to have a way to get around that because you can't fix it. So you have to reset, reboot it somehow? Well, there are a couple of different ways. There's a tendency. You can have, you know, two onboard computers. And if one does not work, then you can switch to the other one. And that's true for other parts in the avionics. If the onboard computer freezes up for some reason, whether it's from radiation hits or whatever, then we say the computer crashed and we will do a reboot. And the reboot is from a permanently stored software program that is on the computer in what they call the EEPROM. And it will enable the satellite to obtain basic functionality to be alive, communicate, et cetera, with the ground. And that will boot back up onto the computer so that the ground can troubleshoot and everything. The satellite often has RAM memory on board where if there have been any updates to the software, they're stored on that, and then they will load that back in once the computer's up and running again. And then that's fairly... Try to get back to the same level. Yeah, that's a fairly common technique. What about updates in the software? Can you send updates like I get from Microsoft all the time? Can you send them and sort of improve, update the actual operating system? As I told you, the software development is often the long pole in the tent. And I was involved with the Clementine lunar mission back in, which was launched in 1994. And we had a three-week journey from the Earth to the Moon. And the purpose of that mission was to do a global map of the Moon, a digital global map of the Moon over a period of two and a half months. Now the software was not fully ready and tested. It was good enough to go into Earth orbit and send us to the Moon, but we weren't ready to map the Moon yet. And so we sent updates to the software on board the spacecraft and we tested it out on the spacecraft so that by the time we got to the Moon, we were able to start the mission. But even while we were doing the mission, and this is true for most spacecraft, especially early in their life, problems were found. And so we'd send updates or what they call patches up to the spacecraft to fix particular problems. And actually Clementine was lost after it left the Moon and was headed to Earth on a roundabout trajectory to the asteroid geographis. And the reason it was lost was due to, mostly to software. And one of the patches that would have fixed it and prevented this was sent to it on the Moon. But the patch had a lunar name on it. The name of the patch was lunar, something or other. So after it left the Moon, the computer crashed and when they brought it back up, they put the patches on that were needed to bring it up to full level. But this particular one, they thought was only needed for the Moon so they didn't update it to the spacecraft. However, they did put it on the version that was in the testbed simulator back in our control center. And so when they tested a new script or a new experiment they were going to do, it worked perfectly in the testbed because it had this patch in. But on the spacecraft, it caused it basically to end the mission. Wow, how interesting. Wow, this is fascinating stuff. So let's talk about your current projects. Cosmos, I recall one of them. And we have some graphics. Why don't you tell us what you've been doing? Okay, when I came to HSFL, my job was to be a project manager to build our first satellite, which is going to be about a 100 kg satellite called HawaiiSat-1. And we needed to be able to operate the satellite and I remembered back to my Clementine days we developed a piece of software that worked very well for controlling our satellite and so we decided to bring that over and use that for our current project in HSFL. And we did a... we built a prototype of it and we submitted a proposal to NASA and they liked the idea of this project so they funded us for three years to develop Cosmos, which... Obviously your logo for Cosmos. Yeah, which Stan stood at that time for the Comprehensive Open Architecture Space Mission Operations System, or Cosmos. And we developed that over three, three and a half years and applied it to our projects. The follow-on to HawaiiSat-1 was called HiakaSat and it actually became the onboard software and the ground software, the ground station software was all controlled by Cosmos. And I'll just point out that the university thought that Cosmos had a lot of potential so in 2014 they invited us to enter their Accelerate UH program and we were in the first cohort to start up a company to develop and market Cosmos. And we did that and the company is called Interstell Technologies Incorporated and when we did that we changed the name of Cosmos and the marketed version which comes through Interstell is called iCosmos, which is Interstell's comprehensive open architecture solution for mission operation systems. And one of the things you notice that in the change of acronym we took the word space out because initially it was designed to control spacecraft and satellites but we were asked by a group in Canada that was doing a feasibility study for the Canadian Space Agency to join them and they wanted to use Cosmos for their operating system not just for their spacecraft but also for their lunar lander and this was a micro rover mission also for controlling the micro rover. So we altered the Cosmos design so that it wasn't limited to spacecraft it could actually control anything, any vehicle at all whether UAV, rover, rocket, satellite, ground station. So I was going to ask you and you kind of answered it if there is a possibility of a commercialization of what you've been doing and obviously there is and what you're doing here in Hawaii is cutting edge and other people with similar space enterprises could use Cosmos or its successor that's happening right now at UH in the accelerator that's fabulous. Have you made a million billion yet? No, we have a lot of organizations and companies that are working with us and evaluating it some of them are in DOD, NASA Goddard, NASA Ames and others are very interested in it and so we're still in the infancy stages of getting it out into the market. Very promising though, right here from UH and one of the differences for Cosmos over existing systems is that it's a nodal architecture in the fact that we interface with nodes and we don't really care what the node is whether it's a spacecraft UAV or something and it all flows into a comprehensive system we have a plug and play architecture which means that someone else's software can be interfaced into a Cosmos makes it modular, they have more marketable and we've taken a lot of attention to the user interface to make it very easy and intuitive to use and that comes from my gaming where I designed computer games and some of the things like one of the computer games was planetary invasion where you had to keep track of a number of planetary invasions and you had a lot of information to keep track of which is very similar to having a number of satellites to keep track of so the user interface method that we used or paradigm we used for that we're also using in Cosmos. There's a crossover between space and games and if you want to see podcast 172 which Trevor did for spacegamejunkie.com you can look that up on spacegamejunkie.com This is Trevor Sorensen, a doctor of engineering at the Space Flight Lab and so has the College of Engineering as you wait for the ones. Thank you so much Trevor. Thank you. It's really been great. Pleasure to be here. Thank you.