Category Archives: Homepage News Item

Using Technology Readiness Levels and System Architecture to Estimate Integration Risk

By Steven D. Eppinger, ScD, Tushar Garg, Nitin Joglekar, PhD, and Alison Olechowski, PhD

The challenge: Risk management is one of the most critical activities in new product development. Improper or insufficient risk identification practices can result in unanticipated schedule overruns, significant rework, budget inflation, and reduced capability for delivering the project’s chartered scope. Although several decision support tools exist to help project managers identify and mitigate risks, few explicitly consider the impact of a system’s architecture.

The approach: This article describes a practical risk identification tool that can be used by engineers and technical managers on projects involving integration of new technology components into systems. Its framework combines system architecture concepts and analysis with technology readiness levels (a metric describing where a given technology is on the path to full maturity) to focus attention on high-risk components and interfaces. It focuses specifically on technical risk, which deals with the uncertainty related to developing and integrating new or complex technologies.

Our goal is to offer a novel risk estimation framework that:

  • includes system architecture considerations;
  • embraces traditional project management literature;
  • defines risk as a combination of likelihood and impact;
  • uses technology readiness levels as a proxy for the likelihood that a component will require a change to fulfill its function;
  • and, given that change propagates through interfaces, employs network measures to estimate impact related to connectivity.

We then:

  • describe how this framework was applied to a project at a high-tech company where data was visualized in different formats to aid in analysis;
  • discuss insights gained from this analysis; and
  • demonstrate that the risk estimation framework provides insight that is in line with the experience of engineers at the company.

For more detailed information, please see our technical article with supporting citations and a thesis.

In developing this framework, we grappled with the following questions:

  • how to estimate technology integration risk using concepts of technical maturity, architecture, and connectivity; and
  • how to keep this assessment effort low enough to enable practical application within industry.

In defining technology integration risk, we focused on concepts of engineering change and change propagation. For highly complex systems, engineering change is required to address mistakes during the design process resulting from uncertainty. In some cases, those changes propagate through interfaces to other components in the system. When mismanaged, relatively small changes can propagate into a cascade of changes that sweep across the system, incurring significant costs and rework. We therefore began our definition by asserting that the technology integration risk of each component i is estimated using a common risk metric—the product of likelihood and impact as seen in this equation:

Riski = Li ∙ Ii

Li is the likelihood that the component technology requires a change to fulfill its function. This is estimated by using technology readiness levels (TRLs), which have been shown to be good estimators of uncertainty in the technology integration process.

Ii is the severity of impact if the component is forced to change. We examined the overall architecture, and the component interfaces specifically, to estimate the impact of context on change propagation.

The following sections describe the rationale and method behind the inputs for our risk calculation. Given that some of our inputs are unbounded scales, we chose to calculate relative risk rather than absolute risk by rescaling all inputs to fall in the 1–10 range. We choose 1–10 for our range as this is the standard used in failure mode and effects analysis.

A. Likelihood of change

There is a relationship between the likelihood of technical or integration problems in design and the degree of certainty that we have about the design, implementation, and capabilities of a particular component or technology. As we design, test, iterate, and integrate the product or system, we drive uncertainty out through a range of validation activities. To include uncertainty in our risk calculation, it was critical to establish a means of measurement. Fortunately, NASA’s TRL scale offered a well-documented, widely used scale for measuring the degree of maturity in a given component. Maturity is also an indicator for uncertainty: Highly mature components have been well-proven in relevant environments and thus have low uncertainty levels. This is precisely the purpose of integration and testing—to minimize uncertainty within the system. The full TRL scale is presented in Table 1.

Table 1. Summary of Technology Readiness Levels from NASA’s Office of the Chief Engineer.

We evaluate each component using this 1–9 TRL scale to get the base likelihood score. Since a TRL of 9 corresponds to the lowest possible uncertainty, and thus the lowest likelihood of manifesting risks, we inverted this scale and made a TRL of 9 correspond to likelihood value of 1, and a TRL of 1 to likelihood value of 9. This produces a vector where the highest value corresponds to the highest likelihood of risks manifesting. As mentioned earlier, we also rescaled the vector linearly so that the range falls between 1–10.

B. Severity of impact

When presented with a specific engineering change, a panel of experienced engineers can provide a rough magnitude estimate of the system impact with relative ease. However, without a specific change instance, it can be difficult to conceive of how impactful future changes to any particular component may be. One approach is to estimate the component’s potential to propagate change.

Change propagation should be closely monitored in development programs because it can lead to unanticipated impacts to costs and schedule. It has been shown that change propagates between components through their interfaces.[1] Therefore, when estimating the potential impact on the overall system, it is reasonable to consider the system architecture and the connectivity of each component.

Because change propagates through interfaces, we propose that components with higher connectivity are more likely to spread change within the system. With this assumption, there are several tools at our disposal to estimate impact severity. System architecture can be analyzed as an undirected network where components are represented as nodes and interfaces as the edges between nodes. With this view, a simple method for estimating the severity of impact would be to count the number of interfaces for each component. In network terms, this would be referring to the nodal degree of the components. After rescaling the degree count for each node to fall between 1–10, we obtained a vector of scores reflecting the severity of risk for each component. The severity score was then multiplied by our likelihood vector to obtain a risk score for each component. The key advantage to this method is ease of calculation. Engineers can compute this risk score for their system with simple tools such as Microsoft Excel and immediately reap the insights.

While nodal degree is a simple measure that can be applied for this analysis, it does not consider architectural characteristics beyond immediate interfaces of the component. Alternative network analysis metrics that account for more indirect change propagation paths could also be useful, such as closeness centrality, betweenness centrality, and information centrality. Each provides a unique perspective on the importance of network nodes; however, they are all highly correlated and in most cases will net similar insights to nodal degree. Still, on occasion there will be some nodes where different measures have significant differences, and generally these nodes have unique characteristics worth examining. Calculating the three centrality measures generally requires specialized software which, while freely available, may be less accessible and more difficult to understand. Practitioners must decide which centrality measure will be most meaningful for their application.

The overall method that we apply in this research is illustrated and summarized in Figure 1.

Summary of method used to calculate risk involved in integrating a new component into a system.

The results: Analog Devices Inc., a large multinational semiconductor company headquartered in Massachusetts, was our industry partner for this research. Together we analyzed a new product development program that is currently under way for a sensor package that could be used to precisely measure angular position. We gathered the following inputs:

  • a decomposition of the system into six subsystems and 20 components,
  • a list of interfaces between every component in the system, and
  • a TRL assessment for every component in the system.

Using these data, we built a view of the system architecture and developed a network representation of the system as illustrated in Steps 1 and 2 from Figure 1. Once all data was collected, we calculated our impact and likelihood vectors as in Steps 3, 4, and 5 of Figure 1 to obtain final risk scores (Step 6). For simplicity’s sake, we demonstrated this example using nodal degree as our measure for impact. The inputs and final risk calculation is shown in Figure 2, with bars in each cell representing magnitudes.

This graphical representation of the components and their change likelihood, change impact, and overall risk scores provides an insightful view of the system integration risk.

To preserve information about interfaces, we combined risk score information with a design structure matrix (DSM) view of the system (Eppinger and Browning, 2012). To do this, we chose each off-diagonal mark in the matrix to represent a risk score composed of the two interfacing components. The calculation is done according to this equation:

Interface riskij = max(Li,Lj) ∙ max (Ii,Ij)

Li and Lj represent likelihood scores for the two interfacing components, and Ii and Ij represent impact scores for each component. We can see the intuition behind this choice in the following example: Suppose a highly uncertain (low-TRL) component were to interface with a highly connected (high-impact) component. If the high-uncertainty component had to be changed during the design process, it is possible that the highly connected component would require a change as well, and it could take careful design and planning to ensure that the change would not propagate beyond that component. Indeed, it may not be possible to fully contain the changes at this highly connected component, and thus you can see the need to scrutinize that interface carefully. Figure 3 enables us to see the results of this analysis. We leave the component-level risk calculations as a vector in the “risk” column as an additional reference.

We presented our findings to Analog Devices team and discussed the results. Analysis suggests the riskiest components were both sensors (Sensor 1 and Sensor 2), followed by the analog-to-digital converters. This aligned with the Analog Devices team’s experience and expectations. In addition, analysis shows the die attach portion of the packaging subsystem is risky. In the early phases of the data collection, the managers had mentioned that the packaging was a point of concern for them, and this is seen in the risk of the die attach.

One manager remarked that the team at Analog Devices implicitly does this kind of risk assessment mentally to gauge risk level of various components in their program. The engineer would consider the “newness” or uncertainty of a component, and the centrality to its role in the system, and use these two ideas to estimate risk. He noted that the newly developed method formalizes the thought process, making it measured and objective.

The technology risk design structure matrix provides an architectural view of the system integration risk for the Analog Devices project.

Next steps: This method could be built into an analytical tool as an add-on to an existing DSM system architecture software toolkit (for an example, see These concepts are already being taught in MIT’s System Design & Management program and in other system-based classes.

This work will be presented at the International Conference on Engineering Design in Vancouver, Canada, in August 2017. The research team continues to pursue research related to technology integration risk, and in particular the technology readiness levels.

[1] P. J. Clarkson, C. Simons, and C. Eckert, “Predicting Change Propagation in Complex Design,” J. Mech. Des., vol. 126, no. 5, p. 788-797, 2004.

About the Authors

Steven D. Eppinger is MIT’s General Motors Leaders for Global Operations Professor, a professor of management science and engineering systems, and the codirector of MIT System Design & Management. His research centers on improving product design and development practices. He holds SB, SM, and ScD degrees in mechanical engineering from MIT.


Tushar Garg is a program manager in the low-voltage and system integration groups at Tesla. He has spent most of his career launching new products at automakers, including Kia, Hyundai, and Toyota. He received an SM in engineering and management from MIT as a graduate of System Design & Management. He also has a BS in mechanical engineering from the University of California, Irvine.


Nitin Joglekar is a dean’s research fellow and associate professor of operations and technology management at Boston University’s Questrom School of Business. His research focus is digital product management. He has a bachelor’s degree in naval architecture from the Indian Institute of Technology, Kharagpur, and two SM degrees from MIT, in mechanical and ocean engineering. He also has a PhD in management science from MIT.


Alison Olechowski is an assistant professor, teaching stream, at the University of Toronto in the Department of Mechanical & Industrial Engineering and the Institute for Leadership Education in Engineering. She has a BSc from Queen’s University and an MS and a PhD from MIT, all in mechanical engineering.


Alum Navigates Systems Challenges to Launch Successful Milk-Chilling Business

Sorin Grama, SDM ’06

By Sorin Grama, SDM ’06

The challenge: Milk is India’s lifeblood. Indians depend on milk for much of their daily nutrition. It is used in curries, the beloved chai, and even for religious rituals. India draws its milk supply from millions of small farmers in villages scattered across the vast countryside. Milk must be collected twice every day, 365 days a year, and rushed to a processing center before it spoils. As a result, the milk supply chain presents a huge challenge for dairy processors.

I learned about this challenge in 2007 when I was visiting India for the first time looking for business opportunities. One of our hosts was a dairy in Bangalore that was having a problem collecting fresh, quality milk. I learned that milk is collected in three steps:

  • Step 1: Individual farmers deliver 5–10 liters of milk to a collection center in a village. A collection center may aggregate from 500 to 2,000 liters of milk per day from 20–40 farmers.
  • Step 2: Milk is picked up and transported to a nearby chilling center. Because refrigeration is not used at the village collection center, the dairy processor needs to pick up the warm raw milk quickly, within 5–6 hours, before it spoils.
  • Step 3: The milk is transported from the chilling center to a processing center where it is pasteurized and processed into such products as cheese and ice cream.

These steps are repeated for thousands of collection centers, twice every day, all over India. It is a huge logistics challenge, and one that I soon discovered could have significant business potential.

One of the farmers who uses Promethean Power Systems’ equipment carries a jug of milk in the village of Mottur in Tamil Nadu, India. (Images courtesy Promethean Power Systems.)

The approach: I began by studying the collection process fully so I could identify the pain points. In 2008 my team and I spent an entire month traveling through rural India following the “milk trail” from farmers to consumers. We made a video of this process so we could later explain the challenge to our US partners and investors.

We learned that the highest pain point in this supply chain was at the source, in the villages where the milk is produced. If milk is not refrigerated immediately after milking, bacteria starts to grow exponentially, changing the taste and eventually spoiling the milk. The sooner milk could be refrigerated, the better it would be for everyone in the system: farmers, processors, and consumers. If milk could be refrigerated at the village, multiple benefits would accrue, including:

  • Lower transportation costs. Milk could be picked up just once a day.
  • Access to additional supplies. Since refrigerated milk lasts considerably longer, the supply chain could extend farther into the countryside.
  • Better milk quality. This benefit is particularly significant since it would allow processors to sell higher-value milk products such as butter, yogurt, and ice cream.

    Figure 1. Traditionally, milk collection in India follows three steps (top image), which means fresh milk typically goes unrefrigerated for several hours—during which time bacteria can grow and spoil the milk. Promethean Power Systems was launched to facilitate a two-step process (bottom image) that refrigerates milk much sooner, curbing the growth of bacteria and preserving milk quality.

    If there are so many benefits to refrigerating milk at the source, I had to ask: Why weren’t dairies doing this? The answer is simple. Refrigeration in rural India is difficult to achieve because of an underlying problem: lack of reliable grid power. The milk supply challenge is really a power infrastructure challenge. If a refrigeration system could be reliably powered, the main problems in this supply chain could be addressed.

    The tools: To understand the problem more deeply, I used contextual inquiries and immersion in my customers’ world, two user-centric design methods I learned in Product Design & Development, a course I took while a student in MIT System Design & Management (SDM). Based on these observations, I decided the best solution would be a stationary milk chiller that could be operated at a village collection center to chill milk immediately after it has been delivered by farmers.

    To design this solution, I used the systems architecture and product design teachings that were still fresh in my mind at the time. I tackled the problem by first decomposing the system into modules that could be designed and developed separately. I then integrated these modules into a final system.

    The two critical modules in this system are: the power module and the refrigeration module. For the power module, I quickly determined that solar power would be the best option. I had some experience with solar power—my SDM thesis was a survey of thin-film solar technologies—and believed that solar power costs would come down dramatically over time. Next, I began to explore different ways to achieve refrigeration efficiently using solar power. I investigated thermoelectrics, absorption chillers, and iceboxes, but I eventually settled on DC-powered vapor compressors.

    Figure 2. Fixing on solar power made it possible to explore multiple concepts for refrigeration.

    The results: My team and I built three prototypes over a period of three years, and with each prototype we learned something new and improved the design. However, the cost of solar power was still prohibitively high, a challenge exacerbated by the difficulty of obtaining the DC components we needed at a reasonable price. The most painful and vivid lesson came when our pilot customer rejected the system as too complex, too expensive, and too difficult to install. We had spent all our time and money to design a beautiful solar-powered refrigeration system only to discover that it was impractical and uneconomical. It was a tough lesson, and it looked as if it would be the end of the road for our startup.

    But there was a glimmer of hope…

    During the process of designing the solar power module, I had also designed a backup subsystem, since solar is not very useful unless you can store the energy and use it later. Because we were dealing only with refrigeration, I chose a simple thermal storage system comprised of a cold water tank. During the day, water can be chilled and stored in an insulated tank. The chilled water can then be used to chill milk in the early morning and late evening. The thermal backup was almost an afterthought, a necessary but not a critical component.

    With a bit of reflection, I realized that we could drop the solar component and instead use the existing power grid with our thermal storage as a backup. The grid is usually available in villages; it just doesn’t always work when you need it. We could charge our thermal battery when the grid was on, and use it as a backup when the grid was off. It was a simpler and more elegant solution. We quickly built a prototype, tested it, and it worked.

    From then on things moved quickly. We iterated and improved on the thermal storage system, which became our differentiator and the source of our competitive advantage over conventional milk chillers, which use diesel backup generators—an expensive option. We eventually patented it and used it for other cooling applications. To date, we have installed more than 600 chilling systems throughout rural India. Each system has a capacity of 1,000 liters and serves the needs of 30 to 40 farmers.

    The lesson: With the benefit of hindsight, I realize the mistake I made during my system design. To be fair, it was a complex system with a lot of moving pieces. I started by fixing on a power source (solar) and investigated different concepts for refrigeration. What I should have done is fixed on a known and economical method of refrigeration (AC-powered vapor compressor) and explored different concepts for generating reliable power: solar, biogas, battery, etc. After all, this was a power infrastructure problem that I was solving, not a refrigeration problem. My bias and preference for solar prevented me from truly exploring the full solution space for this problem. I learned my lesson the hard way, but I don’t regret the journey. Mistakes were costly, but they were also sources of inspiration.

    Figure 3. Ultimately, it became clear that the solution space for India’s milk-chilling challenge should have included additional power source options.

    About the Author

    Sorin Grama, SDM ’07, is the cofounder of Promethean Power Systems, which manufactures and sells milk-chilling systems in India, Bangladesh, and Sri Lanka. After living in India for a few years, Grama is now back at MIT as entrepreneur-in-residence at the Martin Trust Center for MIT Entrepreneurship and the Legatum Center for Development & Entrepreneurship.

    For more information about Sorin Grama, SDM ’07, and his company, Promethean Power Systems, visit

Spring 2017 SDM Tech Trek Report

By Juan Lara, SDM Certificate ’16

Each year, some of MIT’s best and brightest graduate students visit several of the world’s most innovative and successful companies to learn about leadership, innovation, and systems thinking from industry experts—and to explore recruitment opportunities.

Amazon (Photos by Ben Linville-Engler, SDM ’16)

The biannual MIT System Design & Management (SDM) Tech Trek is a tradition that has evolved over the past several years. Organized and run by SDM fellows, the treks were developed to enable SDM students to explore a variety of industries, examine different platforms and technologies, and speak with and learn from leaders at best-in-class companies. These up-close, personal interactions further the students’ education while also strengthening the relationship between SDM and host companies, fostering future opportunities. Two treks are held annually: one in the San Francisco Bay/Silicon Valley area in the spring and one in Greater Boston each fall (see related story below).

During the spring 2017 trek, SDM visited Amazon, C3 IoT, Continental, Ericsson, Google, Intel, Planet Labs, and Tesla. Several of these have sponsored thesis research or other projects; some already have SDM alumni on their staff and/or are looking to hire SDM graduates.

SDM Executive Director Joan S. Rubin remarked on the generosity of the companies visited during the treks. “All of them opened their doors to SDM students and provided unsurpassed opportunities to hear from industry leaders, tour facilities, and experience product/technology showcases and demonstrations. Most importantly, they shared the time, knowledge, and experience of some of their most talented people with the SDM fellows—offering a privileged and much-appreciated opportunity for networking and learning.”

The 2017 spring tech trek was organized and led by SDM 2016 fellows Christian West and Jose Garza. Organizational assistance was provided by all student participants, as well as by Rubin, SDM Director of Recruitment and Career Development Jon Pratt, Logistics and Administrative Specialist Amanda Rosas, and Career Development and Alumni Associate Naomi Gutierrez.

Trip highlights



At Continental’s offices in San Jose, CA, the SDM group met with the company’s vice president and head of products for intelligent transportation systems (ITS), Pasula Reddy; the director of products for Access Solutions ITS, Raj Sundar; and the head of products in China ITS, Yao Zhai. These leaders provided a general corporate overview, described overall industry challenges, discussed the organization’s project development structure; and gave product demonstrations. Later, SDM fellows went on a company tour to see some of the infrastructure put in place to support the company’s evolution. Throughout the visit and during an informal networking session, Continental executives encouraged questions, feedback, and suggestions from the SDMs on what they had seen and heard. Tour hosts included MIT SDM ‘08 alumnus Anil Rachakonda, director of products, Smart Cities ITS, and Heather Pagh of human resources.



Speakers at Ericsson’s facility in Santa Clara, CA, presented an overview and shared the company’s vision for strategy and growth over the short and long terms, focusing specifically on developing new technologies and connectivity for social interactions. They described the role of innovation and the company’s processes to support it, including predictive and optimization models that use data in conjunction with demographics to develop high-value products and services. Tours, product demonstrations, and access to working prototypes showed Ericsson’s commitment to reinvention, innovation, and adaptation over the 140 years of its work in the technology arena. Curtis Ludwig, director of global talent management, was SDM’s host for the visit. Other speakers were: Diomedes Kastanis, head of technology and innovation; Eric Qian, director of product management; Alvin Jude, researcher; and Nese Ozler, who works in the company’s OnSite Experience Center.



At Tesla’s headquarters in Palo Alto, CA, members of the engineering and development teams described the company’s history, products, approach to innovation and design, and several roadmaps for its systems and applications. Students got a glimpse into how fast the company’s culture is evolving to meet aggressive business deadlines. Learning about Tesla’s approach to design and development, as well as how its leaders plan, develop, and execute projects at the highest level in one of the world’s most competitive industries was invaluable.

Planet Labs

Planet Labs

In San Francisco, CA, several Planet Labs leaders met with SDM fellows to deliver presentations. Topics included a company overview; Planet’s approach to agile systems; satellite construction and operation; space deployment methods; and logistics for in-orbit satellites. A discussion followed on product design; methods and tools for development and user feedback; and the discovery of new use cases. SDM fellows received deep insight into a company operating in a small niche market with large demands for data management and reliability; they also gained an understanding of Planet’s business models. Planet representatives included Matthew Ferraro from spacecraft research and development; Ryan Kingsbury from electrical engineering; Cole Murphy from product design; Joseph Mascaro from impact initiatives; Lee Frantz from people services; and Alex Shih SDM ’09 from product and ecosystem, who hosted the visit.

C3 IoT

C3 IoT

At C3 IoT headquarters in Redwood City, CA, the group heard presentations from two MIT alumni—President and CTO Ed Abbo SM ’86 and Director of Products Erick Corona SM MBA ’13. Students learned about the company’s history; how data technologies and connected products interact with society; and what opportunities exist for employing applications in large-scale industries, cyber systems, and data learning. Together with the SDM fellows, Abbo and Corona discussed strategies for rapidly developing products, customizing projects for specific companies/industries; and providing value. The visit concluded with a networking lunch with employees from several of the company’s key departments, including engineering, services, and products.


At Amazon in Tracy, CA, SDM fellows toured the state-of-the-art order fulfillment center, where robots are deployed for product handling, distribution, and manual labor. Students learned how this highly complex, flexible, automated system can quickly be reconfigured and adjusted for variables such as seasonal demand using a robust model that integrates data management inventory and scale. A question-and-answer session that followed the tour covered a variety of topics, including operations metrics; motivating people; the challenges of business growth; and inventory management logistics. Director of Operations Sanjeev Vaid led the visit, which was hosted by Community and Public Relations Specialist Danielle Tafoya.



In Mountain View, CA, students learned how systems thinking was applied at Google to develop the company’s autonomous car spin-off, Waymo. The hosts provided an overview of employee roles and responsibilities in system development for this complex project, and they gave students a look at project management and milestones—all of which aligned remarkably well with what fellows are learning in SDM’s core course. The visit also included a trip to Google’s ACME Lab where they saw how the company uses agile approaches to develop new products and applications as well as to address issues with existing products.


SDMs visited Intel’s product development lab at its San Francisco campus. There they saw how Intel uses rapid prototyping tools, and fellows examined sample products developed by Intel’s design team and marketed by partner companies. On-site discussions that followed focused on the design process, the challenges of developing wearable technology, and Intel’s market strategy.

Key Takeaways

While all the companies visited are technology-driven leaders in their fields, visiting them in rapid succession gave SDM fellows valuable insight into the differences in cultures, strategic and technical approaches, and market challenges—as well as the similarities from business to business.

  • Through meeting and engaging with SDM fellows, company leaders experienced the unique character that MIT SDM fellows share: All are experienced engineering professionals with an average of 10 or more years’ experience, and many already hold one or more advanced degrees. Several companies actively recruit during the trek and/or identify candidates for future recruitment.
  • SDM fellows return to MIT with new professional opportunities and an expanded appreciation of the versatility and applicability of their SDM education across industries.

Upcoming Tech Treks

Twice every year, fellows, faculty, and staff from MIT’s System Design & Management (SDM) program embark on tech treks to learn from leaders at best-in-class companies about how systems thinking is being used to address their most complex business challenges.

SDM will hold two treks in the upcoming year:

  • Fall 2017—a one-day trek to top technology-based companies in the Greater Boston area.
  • Spring 2018—a four- to five-day journey to the Silicon Valley/San Francisco Bay Area that will covers a wide variety of industries.

If your company would like to participate in an SDM Tech Trek, please contact SDM Executive Director Joan S. Rubin at, 617.253.2081; SDM Industry Codirector (Name and contact info) or Director of SDM Recruitment and Career Development Jon Pratt at, 617.327.7106.

MIT Space Hotel Wins NASA Graduate Design Competition

For Immediate Release

MARINA in orbit. MARINA is a proposed concept for a commercially owned and operated space station to replace the International Space Station (ISS) following its planned retirement in the mid-2020s. (All photos courtesy of MIT MARINA team.)

Contact: Matthew Moraguez
Phone: +1 (561) 281-3934

(June 20, 2017) An interdisciplinary team of MIT graduate students representing five departments across the Institute was recently honored at the Revolutionary Aerospace Systems Concepts–Academic Linkage Design Competition Forum. The challenge involved designing a commercially enabled habitable module for use in low Earth orbit that would be extensible for future use as a Mars transit vehicle. The team’s design won first place in the competition’s graduate division.

The MIT project, the Managed, Reconfigurable, In-space Nodal Assembly (MARINA) was designed as a commercially owned and operated space station, featuring a luxury hotel as the primary anchor tenant and the National Aeronautics and Space Administration (NASA) as a temporary co-anchor tenant for 10 years. NASA’s estimated recurring costs, $360 million per year, represent an order of magnitude reduction from the current costs of maintaining and operating the International Space Station. Potential savings are approximately 16 percent of NASA’s overall budget—or around $3 billion per year.

MARINA team lead Matthew Moraguez, a graduate student in MIT’s Department of Aeronautics and Astronautics and a member of Professor Olivier L. de Weck’s Strategic Engineering Research Group (SERG), explained that MARINA’s key engineering innovations include:

  • the extensions to the International Docking System Standard (IDSS) interface;
  • the modular architecture of the backbone of MARINA’s node modules; and
  • the distribution of subsystem functions throughout the node modules.

“Modularized service racks connect any point on MARINA to any other point via the extended IDSS interface. This enables companies of all sizes to provide products and services in space to other companies, based on terms determined by the open market,” said Moraguez. “Together these decisions provide scalability, reliability, and efficient technology development benefits to MARINA and NASA.”

MARINA’s design also enables modules to be reused to create an interplanetary Mars transit vehicle that can enter Mars’ orbit, refuel from locally produced methane fuel, and return to Earth.

A subset of members of the interdisciplinary MIT team that won first place in the graduate division of the Revolutionary Aerospace Systems Concepts–Academic Linkage Design Competition Forum. From left:Caitlin Mueller (faculty advisor), Matthew Moraguez, George Lordos, and Valentina Sumini.

MARINA and SERG team member George Lordos is currently a graduate fellow in MIT System Design & Management (SDM), a program offered jointly by the MIT School of Engineering and the MIT Sloan School of Management. Lordos pointed out that MARINA’s engineering design innovations are critical enablers of its commercial viability, which rests on MARINA’s ability to give rise to a value-adding, competitive marketplace in low Earth orbit.

Lordos also holds a Sloan MBA earned in 2000 and will enter the MIT Aeronautics and Astronautics doctoral program in fall 2017. “Just like a yacht marina, MARINA can provide all essential services, including safe harbor, reliable power, clean water and air, and efficient logistics and maintenance,” said Lordos. “This will facilitate design simplicity and savings in construction and operating costs of customer-owned modules. It will also incent customers to lease space inside and outside MARINA’s node modules and make MARINA a self-funded entity that is attractive to investors.”

Dr. Valentina Sumini, a postdoctoral fellow at MIT, contributed to the architectural concept being used for MARINA and its space hotel, along with MARINA faculty advisor Assistant Professor Caitlin Mueller of MIT’s School of Architecture + Planning and Department of Civil and Environmental Engineering.

“MARINA’s flagship anchor tenant, a luxury Earth-facing eight-room space hotel complete with bar, restaurant, and gym, will make orbital space holidays a reality”, said Sumini.

Other revenue-generating features include rental of serviced berths on external International Docking Adapter ports for customer-owned modules and rental of interior modularized rack space to smaller companies that provide contracted services to station occupants. These secondary activities may involve satellite repair, in-space fabrication, food production, and funded research.

Additional members of the MARINA team include:

* MIT Department of Aeronautics and Astronautics graduate students and SERG members Alejandro Trujillo, Samuel Wald, and Johannes Norheim;
* MIT Department of Civil and Environmental Engineering undergraduate Zoe Lallas;
* MIT School of Architecture + Planning graduate students Alpha Arsano and Anran Li; and
* MIT Integrated Design & Management (IDM) graduate students Meghan Maupin and John Stillman.


Virtual Info Session on Demand

 Learn about the MIT Master’s in Engineering & Management

Designed for mid-career technical professionals, SDM offers full-time, part-time, commuter, and distance options. Graduates receive a master’s degree in engineering and management.

This virtual SDM Information Session highlighted SDM curriculum, matriculation options, industry connections, and career opportunities. SDM faculty, students and staff answered frequently asked questions.