N2 Chart

An N2 chart, also called an N2 diagram or N-squared diagram, is a square grid used in systems engineering to show how the parts of a system connect to each other. The parts, which may be functions or physical components, are listed along the diagonal of the grid. Every other cell represents a possible interface between two of those parts. If something flows from one part to another, such as data, a signal, power, fluid, or a mechanical load, the cell where their row and column meet describes it. If a cell is blank, there is no interface between those two parts.

The name comes from the size of the grid. A system with N parts produces an N by N matrix, which has N squared cells. The chart is simple enough to draw on paper or in a spreadsheet, yet it scales well and makes certain problems visible at a glance: parts with too many connections, missing interfaces, unexpected feedback loops, and clusters of parts that interact heavily with each other but lightly with everything else.

This article explains where the N2 chart came from, how to read and build one, how it relates to other tools such as the functional flow block diagram and the design structure matrix, and how it is used in practice. Worked examples show a functional N2 chart, a physical N2 chart, and how reordering the diagonal changes what the chart reveals.

History

The N2 chart was invented by Robert J. Lano, a systems engineer at TRW, an American aerospace and defense company. It was first published in a 1977 TRW internal report titled The N2 Chart, in the TRW Software Series, Redondo Beach, California. Lano also wrote a 1980 TRW report on structured operational concept formulation, which the IEEE guide on concept of operations documents cites as the first documented use of a ConOps.

The technique spread through the U.S. aerospace and government systems engineering community. NASA's 1995 Systems Engineering Handbook described the N2 diagram as one of three main functional analysis techniques, alongside the functional flow block diagram and time line analysis, and cited Lano's 1977 report. NASA's 2007 revision of the handbook kept the N2 diagram in its discussion of logical decomposition and in an appendix on functional, timing, and state analysis, with an example N2 diagram for orbital equipment. The 2016 revision of the handbook (Rev2) removed that appendix and directed readers to NASA's separate Expanded Guidance for Systems Engineering for N2 diagrams and related techniques.

The Federal Aviation Administration (FAA) included the N2 diagram in its National Airspace System System Engineering Manual, with a section on functional analysis and a separate document on the functional N2 diagram in Version 3.1, dated 2006. IEEE Std 1362-1998, the IEEE guide to concept of operations documents, includes the N2 diagram in its glossary, defining it as a system engineering or software engineering tool for tabulating, defining, analyzing, and describing functional interfaces and interactions among system components, and describing it as a matrix that graphically displays the bidirectional interrelationships between functions and components.

Around the same time as Lano's work, a parallel idea developed in a different community. Donald Steward used matrices to analyze systems of equations in the 1960s and published "The Design Structure System: A Method for Managing the Design of Complex Systems" in IEEE Transactions on Engineering Management in 1981. That line of work became the design structure matrix (DSM), which grew substantially in research and industry use in the 1990s. A static DSM is essentially the same structure as an N2 chart, and the two traditions now overlap heavily.

How an N2 chart is laid out

The diagonal

The diagonal holds the system's elements. In a functional N2 chart these are functions, such as "acquire data" or "control attitude." In a physical N2 chart they are components or subsystems, such as "solar array" or "flight computer." The diagonal cells are the only cells that name things; everything else describes relationships.

Off-diagonal cells

Every off-diagonal cell is a potential interface between the element in its row and the element in its column. NASA's 2007 handbook states the general rule: the square at the intersection of a row and a column contains a description of the interface between the two components on that row and that column. A blank square means no interface exists.

Direction: the clockwise convention

In the classic N2 chart, outputs travel horizontally along an element's row and inputs arrive vertically down an element's column. NASA's 1995 handbook says data flows in a clockwise direction between functions; for example, a symbol showing F1 to F2 indicates data flowing from function F1 to function F2. The design structure matrix literature calls this the IC/FBD convention (inputs in columns, feedback below the diagonal) and attributes it to N2 charts, IDEF0 diagrams, and Gantt charts. The opposite convention, IR/FAD (inputs in rows, feedback above the diagonal), comes from Steward's DSM work. The two are transposes of each other and carry exactly the same information.

So, using the N2 convention:

• To see everything an element produces, read across its row.
• To see everything an element needs, read down its column.
• A cell above the diagonal shows a flow from an earlier element to a later one in the chart's order.
• A cell below the diagonal shows a flow from a later element back to an earlier one: feedback.

The Wikipedia article puts the feedback point this way: if F1 to F2 means data passes from F1 to F2, then F2 to F1 represents feedback. Squares on both sides of the diagonal, not only those next to it, are filled in to show all flows.

What goes in a cell

The transmitted item can be written directly in the cell, for example "temperature readings." For larger charts, NASA's 1995 handbook describes using circles and numbers in the cells that point to a separate list of data interfaces. In physical N2 charts, cells often contain a letter code for the interface type. NASA's 2007 example uses E for electrical, M for mechanical, and SS for supplied services.

Patterns worth recognizing

NASA's 1995 handbook describes several patterns:

• Control loops. A clockwise flow between functions with a feedback loop can be drawn as a larger circle, which the handbook calls a control loop.
• Critical functions. A function with many inputs and outputs to the other functions in its module shows up as a row and column full of entries. NASA's example identifies such a function as critical.
• Modules. Groups of functions that interact heavily with each other but connect to other groups only through a few simple flows form modules. NASA's example shows an upper and a lower module linked by a simple flow at two specific functions, while the lower module has complex internal interactions.

Hierarchy

N2 charts can be decomposed level by level. NASA's handbooks say the chart can be taken down into successively lower levels, to the hardware and software component functional levels. A system-level chart might show six subsystems; each subsystem then gets its own chart showing its internal functions or components, and the system-level cell between two subsystems is expanded into detailed interfaces at the lower level.

Administrative data

The Wikipedia article, based on the FAA manual, notes that each diagram should include minimum contextual and administrative data: the creation date, the name of the creator or organization or working group, a unique decimal-delimited number for the entity, and a unique name for the entity. These details matter when charts are decomposed into many levels and need to be cross-referenced.

What the N2 chart is for

The sources agree on several purposes:

• Defining interfaces. The chart forces the team to state exactly what must cross each interface. NASA says that beyond defining the data that must be supplied across interfaces, the chart pinpoints areas where conflicts could arise.
• Finding problems before integration. Wikipedia describes the goal as pinpointing where interface conflicts may arise so that system integration proceeds smoothly.
• Highlighting dependencies and assumptions. NASA's 2007 handbook says the N2 diagram highlights input and output dependency assumptions and requirements.
• Complementing flow diagrams. The chart complements the functional flow block diagram by showing context between functions at different levels of the model.
• Supporting architecture decisions. Clusters in the chart suggest how functions might be grouped into subsystems, and heavily connected elements flag where interface complexity will concentrate.

Historically, NASA notes that the N2 diagram was used extensively to develop data interfaces, primarily in software, but that it can also be used to develop hardware interfaces.

Counting interfaces

An N2 chart makes the arithmetic of interfaces concrete. With N elements, there are N × N cells, of which N are on the diagonal. That leaves N × (N − 1) off-diagonal cells, each representing one possible directed interface.

The number of possible interfaces grows roughly with the square of the number of elements. Most real systems use only a fraction of the possible cells, but the growth explains why interface management becomes harder as systems get larger, and why architects try to group elements into modules with few connections between groups. The fraction of filled cells, sometimes called density, is a simple measure of how tightly coupled the system is.

Worked example 1: a functional N2 chart

The following example is hypothetical, invented to illustrate the method. It describes a small battery-and-solar-powered weather station that measures conditions, shows them on a local display, and sends them to a remote server.

Step 1: list the functions

Step 2: identify what flows between them

Step 3: fill in the chart

Rows are outputs and columns are inputs. The cell in row Fi and column Fj describes what Fi sends to Fj.

Step 4: read the chart

Several facts jump out:

• Thirteen interfaces are filled out of thirty possible directed cells, a density of about 43 percent.
• F3 is the hub. Its row has four entries and its column has four entries, for eight interfaces in total. Any change to F3's inputs or outputs affects four other functions. In NASA's terms, F3 is a critical function, and its interfaces deserve the most careful definition and testing.
• F6 touches everything. Its row is full: it supplies power to every other function. This is typical of power, thermal, and structure functions, which tend to show up as full rows or columns.
• There are eight entries below the diagonal. Five of them are F6's power outputs. Because F6 is listed last, its outputs to earlier functions appear as "feedback," even though power is not really feedback in the control sense. That is a sign the order of the diagonal could be improved.
• F1 has no inputs except power, and F4 and F5 have no outputs except to F3. That confirms F3 mediates all communication between sensing, display, and communication, which is a deliberate design choice and also a single point of failure worth noting.
• There are no external interfaces shown. In a real chart you would add the outside world: the weather itself as an input to F1, the user as an input to F4, the server as an input to and output from F5, and sunlight as an input to F6. Some charts add an extra row and column for externals; some tools place external inputs in a top row and external outputs in a right-hand column.

Worked example 2: reordering the diagonal

The order of elements on the diagonal is a choice, and it changes what the chart shows. In a time-based or flow-oriented chart, the aim is usually to order elements so that most flows go forward (above the diagonal) and feedback is minimized and kept close to the diagonal. The DSM literature calls this sequencing or partitioning.

In the weather station example, moving F6 (power) to the top of the list gives the order F6, F1, F2, F3, F4, F5:

Now count again:

The system has not changed. Only the order of the diagonal has, but the chart now tells a cleaner story. Power flows forward to everything. Data flows forward from sensing through conditioning to processing and then out to display and communication. The four remaining feedback entries are real control loops: F3 commanding the sampling schedule in F2, the user's buttons feeding back into F3, configuration from the server feeding back into F3, and F3 commanding F6 to sleep or wake. Each of those feedback loops is a place where timing and stability matter, and an engineer would want to look at them closely.

This is the same idea DSM practitioners formalize with algorithms. The Wikipedia article on the design structure matrix lists partitioning methods for time-based DSMs, including path searching, reachability matrices, triangulation, and powers of the adjacency matrix, along with sequencing methods that use optimization or genetic algorithms to minimize feedback loops and keep remaining feedback near the diagonal. For static, component-oriented charts, clustering algorithms reorder elements to group tightly related ones into modules.

Worked example 3: a physical N2 chart

Physical N2 charts show how hardware components connect. The following example is again hypothetical and uses interface type codes similar to NASA's legend, plus D for data:

• M: mechanical (mounting, structural load)
• E: electrical power
• D: data or signal
• T: thermal

Components for the same weather station:

Reading this chart:

• Mechanical interfaces are symmetric. The housing supports every component, and every component bears on the housing, so the M entries mirror across the diagonal. This is common in physical charts. Some teams record a symmetric interface only once.
• The housing has a thermal entry with the power pack. That flags a design question: does the enclosure keep the battery within its temperature limits? A functional chart would not surface that question, because temperature control was not listed as a function.
• The controller has data links to the sensor board, radio, and power pack. Each D entry will need an interface definition: connector, signal levels, protocol, and timing.
• The power pack provides electrical power to three boards, and exchanges data with the controller (battery status and sleep/wake commands from the functional chart).

Each non-empty cell in a physical N2 chart is a candidate for an interface requirement and, on larger projects, an entry in an interface control document (ICD). The chart becomes an index of every interface that must be specified, built, and tested.

Worked example 4: simple metrics and an integration order

Because an N2 chart is a matrix, a few simple counts can be read straight off it. Using the reordered functional chart for the weather station (still hypothetical):

The row totals and column totals both add up to 13, which is a useful self-check: every interface is one element's output and another element's input, so the sums must match. If they do not, a cell has been miscounted.

The counts confirm what the eye already saw. F3 has the most interfaces and F6 has the most outputs. In practice, teams often set extra review or test effort on the elements at the top of this list, because a mistake in a heavily connected element propagates widely.

An integration order from the chart

Now suppose the team wants to decide in what order to bring up the functions on a test bench. A reasonable rule is: integrate an element once the elements that feed it have been integrated, except where a feedback loop forces two elements to be brought up together.

Reading the reordered chart from top to bottom:

1. F6 Power has only one input (sleep/wake commands from F3), and the power function can be tested on its own with that input held in a default state. Integrate first.
2. F1 Sense needs only power. Integrate second.
3. F2 Condition needs signals from F1 and power from F6, both available, plus sampling commands from F3. F2 can be tested with a fixed default schedule standing in for F3's commands.
4. F3 Process needs readings from F2, power and battery status from F6, and inputs from F4 and F5. F3 forms feedback loops with F2, F4, F5, and F6. This is where the bench needs stand-ins (often called stubs or simulators) for the elements not yet connected.
5. F4 Display and F5 Communicate each depend only on F3 and F6 and can then be added, closing the F3 to F4 and F3 to F5 loops.

The feedback entries are exactly the places where the plan needed a stand-in or a default value. That is a general lesson: the cells below the diagonal in a well-ordered N2 chart point to the loops that complicate integration and test, and they show where simulators or test harnesses will be needed.

An interface register

Finally, each filled cell can be numbered and turned into a row of an interface register, the list that larger projects use to track interface definitions:

The ID numbers here are arbitrary; what matters is that each one is unique and never reused. The register connects the chart to the rest of the engineering record.

Connecting the functional and physical charts

The functional chart (example 1) and the physical chart (example 3) describe the same system from two angles. Linking them is called allocation: deciding which component performs each function. A simple allocation for the weather station might be:

Allocation lets the team check the two charts against each other. Every functional interface between functions allocated to different components must appear as a physical interface between those components. For example, F2 to F3 (digitized readings) crosses from the sensor board to the controller, so the physical chart must show a data link from S to C, and it does. F3 to F5 (data packets) crosses from the controller to the radio, so there must be a C to R data link, and there is. Functional interfaces between functions on the same component, such as F1 to F2, both on the sensor board, become internal to that component and drop out of the system-level physical chart, reappearing only in the sensor board's own lower-level chart.

Running this check systematically is one of the most valuable things an N2 analysis can do. A functional interface with no matching physical path is a design gap: the information has no way to get where it needs to go. A physical interface with no functional reason is either a missing function or unnecessary hardware.

How to build an N2 chart, step by step The chart shows that an interface exists; the register says where it is defined, who owns it, and how it will be verified.

How to build an N2 chart, step by step

1. Choose the level and scope. Decide whether the chart shows functions or physical elements, and at what level of the hierarchy. Mixing levels in one chart makes it hard to read.
2. Choose the convention and state it on the chart. Write "outputs in rows, inputs in columns" (or the reverse) in a corner. Charts get shared, and a reader who assumes the opposite convention will misread every arrow.
3. List the elements on the diagonal. Start with a natural order, such as the order of a process flow, and expect to change it later.
4. Work row by row. For each element, ask what it produces and who uses it. Fill in its row.
5. Then work column by column. For each element, ask what it needs and where that comes from. This catches flows that the row pass missed. Discrepancies between the row and column passes are often where design misunderstandings live.
6. Add external interfaces. Show inputs from and outputs to the outside world, either with an extra row and column or a separate list.
7. Look for patterns. Identify hubs, full rows and columns, empty rows (elements that produce nothing anyone uses) and empty columns (elements that need nothing), feedback loops, and clusters.
8. Reorder. Rearrange the diagonal to reduce feedback (for flow-oriented charts) or to cluster related elements (for architecture charts).
9. Decompose. For complex cells or elements, create lower-level charts.
10. Link to interface definitions. Number each interface and connect it to its detailed definition and to the requirements and tests that cover it.
11. Record administrative data such as date, author, chart number, and name, as the FAA guidance recommends.
12. Keep it under change control. An N2 chart is most useful when it reflects the current design.

Relationship to other techniques

Functional flow block diagram (FFBD)

An FFBD shows the sequence of functions as boxes connected by arrows, including parallel paths and decision points. NASA's 1995 handbook notes that while the FFBD shows the logical sequence of what must happen, it does not assign durations. The N2 chart complements the FFBD by focusing on what flows between functions rather than on the order in which they occur. Many teams develop both: the FFBD for sequence and the N2 chart for interfaces.

Time line analysis

NASA lists time line analysis as the third main functional analysis technique alongside FFBDs and N2 diagrams. It adds durations to functions and is used where timing is critical to mission success, safety, or resource use. The three techniques together cover order, interfaces, and time.

IDEF0

IDEF0 is a function modeling method developed under the U.S. Air Force's ICAM program, which produced the IDEF techniques in 1981; it derives from the SADT modeling language. NIST published IDEF0 as Federal Information Processing Standard 183 in December 1993, and that standard was withdrawn in 2008. In IDEF0, each function is a box: inputs enter from the left, outputs leave from the right, controls enter from the top, and mechanisms enter from the bottom. The design structure matrix literature groups IDEF0 with N2 charts under the same inputs-in-columns convention. The arrows in an IDEF0 diagram trace the same kinds of flows an N2 chart tabulates, and an N2 chart can serve as a compact index of an IDEF0 model's arrows.

Design structure matrix (DSM)

The DSM is the closest relative. According to the Wikipedia article on DSMs, a static DSM is equivalent to an N2 chart or to an adjacency matrix in graph theory. DSMs come in several types:

DSM marks have evolved from binary (a link exists or not) to numeric (link strength) to probability (the likelihood that new information causes rework). Multiple-domain matrices combine several DSMs with domain mapping matrices that link, for example, components to the teams responsible for them. The DSM community has developed far more analysis algorithms than the classic N2 tradition, so engineers using N2 charts can borrow freely from DSM methods.

Adjacency matrices and graphs

Mathematically, an N2 chart is a directed graph written as a matrix: each element is a node, and each filled cell is a directed edge. Anything you can do with a graph, such as finding cycles, computing how many steps separate two elements, or finding clusters, you can do with an N2 chart.

Interface control documents

An ICD is the detailed definition of one interface or a set of interfaces: connectors, pin assignments, signal levels, data formats, protocols, mechanical envelopes, and so on. The N2 chart is the map; the ICDs are the detailed descriptions of each road on it. Every non-empty cell should correspond to an interface that is defined somewhere.

Tools and applications

N2 charts can be drawn by hand, in a spreadsheet, or in specialized tools. A spreadsheet is often enough for small charts and has the advantage that anyone can open it.

Systems engineering modeling tools generate N2 views from the underlying model. For example, the documentation for Vitech's GENESYS tool describes an N2 diagram view in which items appearing in the top row are inputs or triggers that come from functions not shown on the diagram, a practical extension for showing external interfaces.

N2-style diagrams also appear outside classic systems engineering. The open-source OpenMDAO framework for multidisciplinary design analysis and optimization uses an N2 diagram to visualize its models. Its documentation describes a model hierarchy on the left, a connection matrix in the center, and solver hierarchy on the right, with marked cells in the lower triangle showing upstream connections in terms of execution order and indicating which systems and components are involved in a convergence loop. That is the same feedback idea from Lano's chart, applied to coupled engineering computations.

The INCOSE Systems Engineering Handbook includes an appendix that presents an N2 diagram of the systems engineering processes themselves, showing how the outputs of one process become inputs to another. This is a good illustration that the elements on the diagonal can be processes and organizations, not only hardware and software.

Typical uses include:

• Defining data interfaces in software-intensive systems, the historical primary use
• Hardware interface definition, as in NASA's orbital equipment example
• Organizing interface control documents on large programs
• Planning integration and test order, since elements with no unmet inputs can be integrated first
• Spotting candidates for modularization or standardization
• Process analysis, where the diagonal holds activities or departments and the cells hold handoffs

Common pitfalls

• Ambiguous direction. If the chart does not say which convention it uses, readers may interpret every interface backwards.
• Mixing levels. Putting a whole subsystem and a single sensor on the same diagonal hides detail in one place and overwhelms it in another.
• Mixing functions and components. A chart that lists "process data" next to "controller board" confuses what something does with what it is. Keep functional and physical charts separate, and relate them through allocation.
• Vague cell contents. A cell that says "data" or "interface" tells the reader almost nothing. Name the item that flows.
• Ignoring external interfaces. Many integration surprises come from the boundary with the outside world, not from internal interfaces.
• Leaving it unordered. The first order you choose is rarely the most informative. Reordering to reveal flow or clusters is part of the analysis.
• Letting it go stale. A chart that no longer matches the design is worse than none, because people trust it.
• Unreadable size. Very large charts become hard to use as a single view. Decompose them into levels, or use a tool that supports filtering and zooming.

Misconceptions

"An N2 chart is only for software." NASA notes it was used mainly for software data interfaces historically, but it also applies to hardware, and its examples include mechanical, electrical, and supplied-service interfaces.

"The N2 chart shows the order things happen in." It shows what flows between elements. The diagonal order can be chosen to reflect a process sequence, but the chart itself does not show timing or sequence the way an FFBD or timeline does.

"Below-diagonal entries are always real feedback." They are feedback only relative to the chosen order. As the reordering example shows, moving an element can turn apparent feedback into forward flow. True feedback loops are the ones that remain no matter how you reorder.

"N2 charts and DSMs are different tools." They have different histories and communities, and DSM practice includes more analysis methods, but a static DSM and an N2 chart are structurally the same thing, differing at most by which convention they use for rows and columns.

"A blank cell means nobody has thought about it." A blank cell means there is no interface. That is a meaningful statement and should be confirmed, not assumed. If two elements are not supposed to interact, a blank cell can also become a requirement (for example, no electrical connection between two isolated circuits).

Frequently asked questions

Why is it called N2?

Because a system with N elements produces an N by N grid with N squared cells. It is read as "N squared."

Who invented the N2 chart?

Robert J. Lano at TRW, first published in a 1977 TRW report titled The N2 Chart.

Which way do the arrows go?

In the classic convention, outputs go horizontally along an element's row and inputs come vertically down its column, so flow runs clockwise around the diagonal. Some practitioners, especially in the DSM tradition, use the transpose. Always check the chart's stated convention.

What is the difference between a functional and a physical N2 chart?

A functional chart lists functions on the diagonal and shows what information, material, or energy passes between them. A physical chart lists components and shows how they are connected mechanically, electrically, thermally, or by data. Teams often build both and relate them by allocating functions to components.

How big can an N2 chart get?

There is no fixed limit, but readability falls off quickly. Large systems are handled by decomposition: a top-level chart of major elements, with lower-level charts for each element's internals.

How does an N2 chart help with integration and testing?

Each filled cell is an interface that must be verified. Integration can be planned so that elements are assembled in an order that satisfies their inputs, and feedback loops identify where elements must be integrated together because they depend on each other.

Can one cell hold more than one kind of interface?

Yes. A cell can list several items, as in the physical example where the power pack sends both electrical power and data to the controller ("E, D"). If cells become crowded, switch to numbered references that point to a separate interface list, the approach NASA's 1995 handbook describes.

How is an N2 chart different from a block diagram?

A block diagram draws elements as boxes and interfaces as lines, which is intuitive but becomes tangled as the number of elements grows, and blank space on a block diagram does not tell you whether an interface was considered and ruled out. An N2 chart gives every possible pair a cell, so completeness can be checked cell by cell, and its layout does not depend on where someone chose to draw the boxes. Many teams use a block diagram for presentations and an N2 chart for analysis and checking.

Do I need special software?

No. A spreadsheet works for most small and medium charts. Modeling tools are useful when the chart needs to stay synchronized with a larger system model.

Summary

The N2 chart is a square matrix that puts a system's elements on the diagonal and its interfaces everywhere else. Invented by Robert J. Lano at TRW and first published in 1977, it became a standard functional analysis tool in NASA and FAA systems engineering guidance and is closely related to the design structure matrix developed from Donald Steward's work. Its power comes from its simplicity: by forcing a team to fill in every cell, it exposes missing interfaces, overloaded elements, feedback loops, and natural modules. Used with a clear convention, a sensible ordering, and links to detailed interface definitions, it remains one of the most practical tools for understanding how a complex system fits together.

Sources

• N2 chart (Wikipedia)
• NASA Systems Engineering Handbook, SP-6105 (June 1995), archived
• NASA Systems Engineering Handbook, NASA/SP-2007-6105 Rev1 (NTRS)
• NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2
• FAA NAS System Engineering Manual v3.1, Section 4.4, archived
• IEEE Std 1362-1998, Concept of Operations Document (IEEE Xplore DOI)
• Design structure matrix (Wikipedia)
• DSM Web: Reading a DSM
• IDEF0 (Wikipedia)
• Eppinger and Browning, Design Structure Matrix Methods and Applications (MIT Press)
• OpenMDAO documentation: Details of the N2 Model Visualizations
• Vitech GENESYS help: N2 Diagram
• INCOSE Systems Engineering Handbook, Appendix D: N2 Diagram of Systems Engineering Processes (O'Reilly listing)