Overview of SAE J1939 and Recent CAN FD/XL Enhancements
SAE J1939 Basics: SAE J1939 is a high-level communications protocol that has long used the CAN (Controller Area Network) bus for in-vehicle networking on heavy-duty and off-road vehicles (e.g. trucks, agricultural and construction machinery). It operates on a 29-bit CAN identifier (extended frame) and typically at 250 kbps data rate (with some newer implementations at 500 kbps) – meaning it can carry 8-byte messages with fairly low latency (Source: https://en.wikipedia.org/wiki/SAE_J1939). J1939 organizes data into Parameter Group Numbers (PGNs) and supports multi-packet transport for data up to ~1785 bytes if needed (using a transport protocol layer), but its bandwidth is limited by the CAN 2.0 physical layer (Source: https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial). This became a bottleneck as vehicle systems grew more complex.
Need for Higher Bandwidth: Modern off-road vehicles are increasingly equipped with advanced sensors, actuators, and controllers (for emissions, safety, automation, etc.). Traditional J1939 (using Classical CAN) at 250 kbps cannot easily support the growing data demands – for example, high-resolution sensor data, detailed diagnostics, or ADAS (Advanced Driver Assistance) signals. To address this, SAE introduced J1939-17 and J1939-22, which update J1939 to use CAN FD (Flexible Data Rate) as the data link layer (Source: https://jcom1939.com/sae-j1939-22-features-and-improvements-of-can-fd-based-j1939). CAN FD allows a switch to a faster bit rate after arbitration and permits up to 64 bytes per frame. In practice, J1939 over CAN FD is standardized to run at 500 kbps during arbitration and 2 Mbps during the data phase (Source: https://copperhilltech.com/blog/sae-j1939-and-the-challenging-migration-from-classical-can-to-can-fd-and-can-xl/). This roughly quadruples the throughput for J1939 messages and provides eight times larger payload per message. SAE officially released these CAN FD-based J1939 specs in 2021-2022 (Source: https://www.sae.org).
Backwards Compatibility Challenges: A key issue with J1939 over CAN FD is that CAN FD is not backward-compatible with Classical CAN on the same bus – a CAN FD frame will not be understood by a classical CAN-only device, and mixing them on one network can’t work (Source: https://copperhilltech.com/blog/automotive-ethernet-expected-to-gradually-replace-traditional-can-bus-network-backbone/). This means manufacturers must either use separate networks for classical CAN J1939 and CAN FD J1939 or entirely upgrade existing networks to CAN FD. In practice, an off-road vehicle might retain the existing 250 kbps CAN bus for critical engine/vehicle controls and add a new high-speed CAN FD bus for data-intensive devices. The J1939 committee is actively working on network bridging solutions (via a Network Interface ECU) to allow a gateway between a classical CAN J1939 segment and a CAN FD segment, but timing and transport issues make this complicated (Source: https://kvaser.com/q1-2025-j1939-and-vehicle-controls-blog/). The evolutionary approach of “CAN FD J1939” is seen as a compromise – it yields more bandwidth without completely abandoning CAN (which is well-understood and rugged), but it introduces complexity in maintaining compatibility.
CAN XL – Future Extension: Beyond CAN FD, the CAN community (CiA – CAN in Automation) has been developing CAN XL (Extra Large), a next-generation CAN protocol supporting data rates up to around 10 Mbps and payloads up to 2048 bytes per frame (Source: https://copperhilltech.com/blog/sae-j1939-and-the-challenging-migration-from-classical-can-to-can-fd-and-can-xl/). The idea is to fill the gap between CAN FD and automotive Ethernet. CAN XL is designed to be backward-compatible with CAN FD (so new controllers could fall back to FD), learning from the issues with CAN FD’s break in compatibility (Source: http://www.can-newsletter.org/engineering/standards/190730_can-xl-discussions-at-cias-17th-iaa-pavilion_cia/). The SAE J1939 committee has begun exploratory discussions on carrying J1939 over CAN XL, potentially reusing the same “Contained PG” packing concept used in J1939-22 (CAN FD) to bundle multiple 8-byte J1939 messages into one large frame (Source: https://kvaser.com/pt2-q1-2023-j1939-vehicle-control/). However, this is in very early stages – no decision has been made, and industry adoption of CAN XL is still some years out. Some experts even question if CAN XL will gain traction before automotive Ethernet renders it obsolete for high-bandwidth needs (Source: https://copperhilltech.com/blog/sae-j1939-and-the-challenging-migration-from-classical-can-to-can-fd-and-can-xl/). For now, CAN XL remains a potential future path for J1939 if additional bandwidth is required without moving entirely to Ethernet.
Overview of NMEA 2000 and the OneNet Transition
NMEA 2000 (Marine CAN Network): NMEA 2000 (N2K) is the maritime industry networking standard introduced in 2001 by the National Marine Electronics Association. Technically, NMEA 2000 is built on SAE J1939 – it uses the same CAN 2.0B protocol at 250 kbps and similar PGN messaging format, adapted for marine equipment like GPS, engines, sensors, and navigation displays (Source: https://en.wikipedia.org/wiki/NMEA_2000). NMEA 2000’s plug-and-play network allows up to around 50 physical devices (and an address space up to 252 nodes) on a boat to communicate over a single CAN bus. It has been very successful in enabling interoperability of multi-vendor marine electronics (e.g., you can plug a fuel sensor from one manufacturer and a display from another onto the N2K bus and they work together). However, like J1939, NMEA 2000 is constrained by CAN bandwidth and 8-byte message sizes. This is fine for sending GPS position, engine RPM, fluid levels, etc., but it struggles with heavier data. By the 2010s, new marine technologies (such as high-resolution sonar imaging, radar scans, video surveillance feeds, and internet data) demanded far greater throughput than 250 kbps.
Strategic Decision – Skip CAN FD, Embrace Ethernet: Notably, the NMEA faced a strategic fork in the road similar to SAE’s: whether to extend NMEA 2000 with CAN FD (to get a modest boost in speed to 2 Mbps) or to jump to a fundamentally higher-bandwidth solution. The NMEA made a conscious decision not to create a “NMEA 2000 on CAN FD” standard. Instead, they developed NMEA OneNet, an Ethernet-based marine networking standard (Source: https://copperhilltech.com/blog/automotive-ethernet-expected-to-gradually-replace-traditional-can-bus-network-backbone/). OneNet was announced in the 2010s and the official OneNet 1.0 standard was released around 2020 (Source: https://www.nmea.org/Assets/nmea-onenet-standard-press-release-10-2020.pdf). The rationale was that moving to Ethernet/IP would provide orders of magnitude more bandwidth (and room for growth) to support modern marine electronics, whereas CAN FD’s improvement (from 0.25 to 2 Mbit/s) might still fall short for things like streaming sonar data or video. Additionally, since NMEA 2000 networks on boats are generally smaller and simpler than whole vehicle networks, adding an Ethernet backbone was seen as a manageable step.
What is OneNet?: NMEA OneNet is essentially an IPv6 and Ethernet-based framework designed to carry NMEA 2000 messages (and other data) over standard networks. OneNet is built on IEEE 802.3 Ethernet (the same physical layer as office or automotive Ethernet) and uses IPv6 addressing. It’s often described as “NMEA 2000 on steroids” – effectively, it allows the same type of NMEA 2000 PGN messages to be encapsulated and transported over Ethernet, but with much higher capacity (Source: https://panbo.com/onenet-nmea-finally-creates-a-marine-ethernet-standard/). Key features of OneNet include:
-
High Bandwidth: OneNet supports 100 Mbit/s, 1 Gbit/s, and even up to 10 Gbit/s network speeds depending on the chosen Ethernet hardware. In effect, this can be 400 to 40,000 times faster than NMEA 2000’s 0.25 Mbit/s (Source: https://www.nmea.org/nmea-onenet.html). This bandwidth easily accommodates video feeds, radar imaging data, sonar point clouds, and other large data streams in a way CAN could not.
-
IP Network Architecture: OneNet uses standard IP protocols. This means OneNet devices obtain IPv6 addresses, and standard networking services can be used. It supports automatic device discovery, use of existing Ethernet switches/routers, and the ability to carry other IP traffic in parallel. For example, a single Ethernet cable on a boat could carry OneNet messages and other services like streaming media or internet traffic without conflict (Source: https://www.nmea.org/nmea-onenet.html).
-
Large Network Size: Ethernet (with IPv6) allows thousands of devices on a network. OneNet drastically expands the device count beyond N2K’s ~50 device practical limit (and 252 address limit). In theory, over 65,000 devices could coexist on a OneNet IPv6 subnet (practically, of course, a boat won’t have that many, but it removes network size constraints) (Source: https://panbo.com/onenet-nmea-finally-creates-a-marine-ethernet-standard/).
-
Power over Ethernet (PoE): OneNet specifies the use of PoE to deliver up to about 25 watts to devices directly via the Ethernet cable (Source: https://www.nmea.org/nmea-onenet.html). This is similar to how NMEA 2000 supplies power on the CAN bus for small sensors, but with higher power for devices like IP cameras or displays.
-
Interoperability and Gateways: OneNet is designed to complement, not immediately replace, NMEA 2000. NMEA 2000 remains for critical real-time sensor and control data, while OneNet can carry high-bandwidth data and serve as a backbone. The standard includes definitions for gateways between N2K (CAN) networks and OneNet (Ethernet) networks so that messages can flow between them (Source: https://www.nmea.org/nmea-onenet.html). For example, an engine might only have a N2K CAN interface, but a OneNet gateway on the boat can send that engine’s data to a OneNet-based glass cockpit display over Ethernet.
Real-Time Considerations: One important caveat is that OneNet (Ethernet) is not recommended for time-critical control data that requires real-time determinism. NMEA specifically points out that the CAN-based NMEA 2000 network offers prioritization and guaranteed delivery for critical messages (via CAN’s bus arbitration and error-checking mechanisms), whereas standard Ethernet lacks inherent message prioritization and can suffer from collisions or delays unless special protocols (like Time-Sensitive Networking) are used (Source: https://panbo.com/onenet-nmea-finally-creates-a-marine-ethernet-standard/). For this reason, NMEA envisions OneNet as an addition rather than a replacement: propulsion engines, throttle controls, and emergency signals will likely remain on NMEA 2000 CAN, while non-critical but data-heavy systems (surveillance cameras, sonar imaging, detailed chart data) run on OneNet. In practice, modern marine systems will use a hybrid network: a CAN bus for core sensor/actuator control and an Ethernet network for multimedia and big data. This strategy allows leveraging the strengths of each network type.
Strategic Implications for Off-road Vehicle Manufacturers
Off-road vehicle manufacturers (encompassing agriculture, construction, mining machinery, trucks, etc.) are at a crossroads with their networking strategy. Historically, SAE J1939 over CAN has been the backbone for engine and machine control, and it’s deeply ingrained – with a huge ecosystem of J1939-compatible ECUs and decades of field-proven reliability. The question is how to handle the ever-increasing data demands (for advanced functions like precision farming sensors, autonomous operation, high-definition cameras, and telematics) while maintaining the robustness and real-time capabilities of J1939.
The current strategy in the off-road industry appears to be incremental evolution: adopt CAN FD within the J1939 framework to get some bandwidth relief, and explore adding dedicated high-speed links for specific needs. For instance, manufacturers can upgrade certain buses to J1939-22 (CAN FD) where appropriate – this gives up to 8× data payload per message and faster transmission, which can help with transferring larger data chunks (like diagnostic information or complex sensor readings) more efficiently. It’s a way to extend the life of the CAN-based network and delay the need for more radical changes. Importantly, using CAN FD is a relatively cost-effective step because it doesn’t require the kind of hardware overhaul an Ethernet network would (Source: https://jcom1939.com/sae-j1939-22-features-and-improvements-of-can-fd-based-j1939). Many existing CAN controller chips are available in drop-in form that support CAN FD, and the software layers (J1939 protocol logic) can remain largely similar aside from the transport changes. This evolution-over-revolution mindset aligns with the conservative nature of heavy vehicle industries where backward compatibility, supplier continuity, and reliability are paramount.
However, manufacturers must manage the transition complexity. If a new tractor model uses some J1939 CAN FD devices and some classical CAN devices, the network segmentation and gateway logic need to be designed carefully. One approach is to implement gateway ECUs that bridge between old and new segments, but as noted earlier, this can introduce latency or complexity in ensuring all messages arrive in a timely manner. Another approach is to dedicate the CAN FD bus to entirely new functions (so legacy devices stay on the old bus, and there’s minimal cross-communication needed). In some cases, off-road OEMs might opt to keep the critical control loops on the classical CAN J1939 bus (for absolute determinism and because 250 kbps is actually sufficient for low-frequency control data like engine RPM, pressures, etc.), and use a separate CAN FD bus for, say, advanced sensors or high-speed logs.
The looming question is whether Automotive Ethernet eventually becomes part of off-road vehicle networks as it has in passenger cars. We already see hints of this: the SAE J1939 committee’s “Next Generation” task force and others are looking into use cases that require more than CAN FD can offer. For example, an upcoming SAE J3271 standard is defining a megawatt charging interface for electric trucks and machinery, and it plans to use two CAN channels and two Ethernet channels to manage communication between the vehicle and charger (carrying control plus high-volume data like video from cameras for alignment, etc.) (Source: https://kvaser.com/q1-2025-j1939-and-vehicle-controls-blog/). This indicates a pragmatic approach – use CAN where its strengths lie (robust real-time control) and introduce Ethernet for high-bandwidth links when necessary. Off-road manufacturers are likely to follow the automotive industry in adopting Ethernet for things like camera systems, firmware updates, and connectivity, but they may not replace J1939 CAN for core operations in the near term. Instead, Ethernet might exist in parallel as a backbone or for specific subsystems (just as NMEA is doing with OneNet on boats).
In summary, the strategic direction for off-road vehicles is a hybrid network strategy with an evolutionary upgrade of CAN. They will leverage J1939 over CAN FD to ease bandwidth pressure in the short-to-medium term, evaluate CAN XL down the road (if it becomes viable and standardized, to further extend CAN’s relevance), and gradually integrate Ethernet for features that demand it (like high-res imaging or external communications). This allows them to protect the huge investment in CAN-based infrastructure and expertise while still meeting new technological requirements.
Strategic Implications for Marine Electronics Developers
Marine electronics developers (and boat/ship builders) have a slightly different set of priorities and constraints. In the marine world, networks like NMEA 2000 are used not just for engine control, but for a wide array of sensors and user-interface devices (chartplotters, depth finders, autopilot, etc.). The data diversity is large – from tiny temperature readings to large radar scan files – and the marine consumer increasingly expects seamless integration of all these on their vessel’s network.
The move to OneNet (Ethernet) reflects a strategic choice to accommodate the high-end data needs of modern marine systems. By choosing Ethernet/IP, the marine industry essentially aligns itself with mainstream networking technology. This has several strategic implications:
-
Future-Proofing Bandwidth: OneNet provides a huge headroom for future growth in data requirements. Marine developers can design new sonar systems or 4K engine room cameras without worrying if the network can handle it – a Gigabit Ethernet link has plenty of capacity. This encourages innovation in marine sensors and entertainment systems, knowing that the network won’t be a bottleneck. It also means the marine industry can piggyback on evolving Ethernet standards (e.g., 10 Gbps, 40 Gbps in the far future, optical fiber backbones on superyachts, etc.) relatively easily. In contrast, trying to push more through CAN (even CAN XL at 10 Mbps) might have hit a wall fairly soon for these big-data applications.
-
Integration with IT and IoT: Since OneNet is IP-based, it fits naturally into the Internet of Things (IoT) ecosystem. A boat’s OneNet network can connect directly to satellite or cellular routers, cloud services, and mobile devices. For manufacturers, this means they can offer features like remote monitoring, over-the-air updates, streaming of data off the vessel, etc., using standard IP solutions. It lowers the barrier to entry for new players who are more IT-focused as well. The strategic bet here is that leveraging Ethernet and IP will speed up development and integration, as opposed to training developers in specialized CAN protocols.
-
Maintaining Reliability via Dual Networks: The NMEA’s guidance to retain NMEA 2000 for critical control means that marine developers will effectively design systems with dual-network architecture. For example, an engine control unit might output essential engine data (RPM, temperature, alarms) on NMEA 2000 and simultaneously send bulk data (like a full engine diagnostic download or high-speed sensor data) over OneNet. The autopilot, which needs instantaneous command of the rudder, will likely listen on NMEA 2000 because of its real-time reliability, whereas a mapping application that aggregates data from many sources can pull those over OneNet. Strategically, this means device manufacturers need to build in both CAN and Ethernet interfaces on many products, or provide gateway devices. There is added cost and complexity in the short term – but it is considered worthwhile for the performance gains. Over time, as Ethernet-based networking (with QoS or time-critical extensions) matures in marine use, we may see more functions migrate to OneNet entirely, but that will depend on proving that Ethernet can be as trustworthy as CAN in all conditions (including electrical noise, power disruptions, etc., which CAN is known to handle well).
-
Standardization and Industry Support: OneNet being an NMEA standard ensures that there is a common playing field – multiple marine electronics companies have collaborated on it. Already, we see broad industry support; major marine electronics manufacturers are part of the OneNet committee. The OneNet certification program is also key: devices will be tested for compliance just like NMEA 2000 devices are, to ensure interoperability (Source: https://panbo.com/nmea-releases-onenet-ethernet-standard-panbo/). From a strategic perspective, this widespread support reduces the risk for developers to adopt OneNet (as opposed to each company inventing its own proprietary Ethernet solution). It’s a unified move, which is likely to accelerate adoption once the first wave of OneNet-enabled products hits the market.
In summary, marine electronics makers are embracing a two-network strategy with an emphasis on Ethernet for growth. They acknowledge that CAN-based NMEA 2000 remains essential for its reliability in core functions, but they are boldly pushing into Ethernet to unlock new capabilities. This positions the marine industry to handle the data-rich applications of the future (from high-detail sonar to multi-function displays sharing data across the boat) and keeps marine technology in sync with the broader trends of connectivity and IoT. The strategic outcome is likely a rapid expansion of what marine networks can do, enabling smarter and more connected vessels, while still keeping the safety-critical systems on a rock-solid CAN foundation.
Comparative Analysis and Key Attributes
To highlight the differences and similarities between the J1939 enhancements path and the NMEA 2000/OneNet path, click here for a table summarizing the key attributes.
Analysis: Both off-road and marine industries face the challenge of increasing data needs outstripping the limits of Classical CAN. The off-road sector, via J1939, has pursued enhancements of the CAN technology itself (CAN FD, CAN XL) to incrementally boost capacity while maintaining the familiar CAN environment. This path prioritizes interoperability with existing systems and leverages the reliability and real-time strengths of CAN – but it results in only moderate bandwidth improvements (from 0.25 Mbps to a few Mbps). In contrast, the marine sector (NMEA) strategically chose to leap to Ethernet (OneNet), gaining two orders of magnitude more bandwidth and aligning with mainstream networking, at the cost of increased system complexity and a split architecture (maintaining CAN for some uses and Ethernet for others). Marine OneNet provides a much larger performance jump than CAN FD can, which is crucial for data-heavy marine sensors, but it requires careful integration to preserve the deterministic behavior for critical control messages. Off-road vehicle makers appear more cautious, introducing Ethernet only as needed and trying to get more mileage out of CAN through standards like J1939-22. Over time, both industries may end up with hybrid networks – a high-speed Ethernet backbone plus multiple CAN sub-networks – but the timing and emphasis differ. NMEA’s OneNet is an official, full-fledged Ethernet standard for marine, whereas SAE J1939’s CAN XL discussion is still preliminary and there is no “J1939 over Ethernet” standard (automotive and off-road Ethernet implementations tend to use other protocols like SOME/IP or custom arrangements rather than J1939).
The different approaches also reflect different use-case priorities: Off-road machines usually don’t need to stream video or other extremely large data internally (those that do, like autonomous vehicles, are indeed adding Ethernet), so a 2 Mbit CAN FD bus can address many of their near-term needs (like more diagnostic data, more ECUs on the network, etc.). Marine vessels, on the other hand, increasingly do have high-bandwidth data (e.g., sonar, radar, video cameras) as core parts of their electronics suite – thus necessitating a faster network sooner.
Adoption Trends and Outlook
Off-road (J1939) Adoption Trend: The adoption of CAN FD in the off-road and heavy vehicle space is expected to be gradual and alongside existing networks. Since J1939-22 became available in 2022, initial deployments are likely in high-end applications or new platforms where the additional bandwidth is immediately beneficial (for example, next-gen diesel engines with extensive emission control data, or electric vehicles needing to communicate battery and motor data quickly). Over the next 5+ years, more manufacturers will include at least some CAN FD capability in their vehicles. We can anticipate a period where vehicles have multiple J1939 networks: one or more classical CAN buses and one CAN FD bus, each handling different data domains. By the late 2020s, if CAN XL matures and if CAN FD bandwidth starts to feel tight, we might see early trials of J1939 over CAN XL. However, there is also a chance that by that time, the industry might skip CAN XL and adopt Automotive Ethernet for the really demanding data (especially given the automotive sector is pushing Ethernet strongly – economies of scale will make Ethernet cheaper and more compelling). Indeed, features like driver assistance, camera-based systems, and high-speed telemetry in trucks or off-highway machines might use Ethernet (often via protocols like Time-Sensitive Networking to get determinism) well before CAN XL ever becomes a necessity. Therefore, the likely mid-term scenario for off-road is a mix of CAN and Ethernet, with J1939 continuing to handle the core control communications (possibly upgraded to CAN FD), and Ethernet introduced for high-bandwidth components. Manufacturers and suppliers will continue working through standards (SAE and ISO) to ensure security (as seen with J1939-91C for security over CAN FD, etc.) and interoperability in this multi-network environment.
Marine (NMEA) Adoption Trend: In the marine domain, NMEA OneNet is currently at the transition’s dawn. The standard is published (v1.0), and tools for certification and implementation have been rolling out. The adoption is expected to start with larger vessels and complex systems – for instance, a big yacht or commercial ship that has multiple radar units, high-end fish-finders, video cameras, and needs to integrate them on a network will be an early candidate to install a OneNet backbone. These early adopters will likely deploy OneNet switches and gateways alongside the traditional NMEA 2000 backbone. We’ll see marine electronics manufacturers releasing OneNet-compatible versions of their products: e.g., a radar that outputs data directly onto Ethernet, or a gateway that funnels a cluster of NMEA 2000 sensor data onto OneNet for a central display. Given the marine industry’s pace, a conservative estimate is that over the next 5 years (2025-2030), OneNet will go from early adoption to a more commonplace feature on mid to high-end boats. NMEA 2000 will still be present on those boats (and certainly on smaller boats where high-speed data isn’t needed). Over a longer horizon, as confidence in Ethernet grows, more and more data types might migrate to OneNet. It’s plausible that in a decade or two, a new boat might have almost all its devices on an Ethernet network and only keep a minimal CAN network for certain redundant fail-safe communication. But that will depend on how reliable and cost-effective the Ethernet solutions prove in the harsh marine environment (salt, moisture, electrical noise). OneNet’s success also ties to the broader trend of IoT in marine – boat owners expect their vessel’s data on their phone, manufacturers provide cloud services, etc. OneNet makes those integrations much easier, so there is strong impetus for its adoption.
Cross-Industry Influence: It’s worth noting that the off-road vehicle industry and marine industry often observe each other’s technology moves, since both use J1939-based protocols historically. The marine sector borrowing J1939 for NMEA 2000 shows that cross-pollination. Now, the off-road sector might watch marine’s experience with Ethernet. If OneNet is very successful and marine demonstrates that a mixed CAN/Ethernet network can be managed well (maintaining safety while vastly expanding capability), that could encourage more aggressive Ethernet adoption in off-road machines as well (for instance, construction equipment using Ethernet for high-def sensor fusion systems). Conversely, if off-road finds a smooth path with CAN FD and maybe CAN XL that delays the need for Ethernet in certain domains, marine might also adopt some of those lessons for smaller boats (where running an Ethernet cable might be overkill if a simpler CAN XL bus could suffice for moderately higher bandwidth than N2K).
In conclusion, SAE J1939’s enhancements (CAN FD, XL) and NMEA’s OneNet represent two different strategies to the same problem: how to increase data throughput and network capability for modern applications. Off-road vehicles stick closer to their legacy – pushing the CAN technology to its limits – an approach that minimizes disruption and leverages existing strengths (robustness, real-time control). Marine electronics decided to augment their legacy system with a new one – jumping to Ethernet to gain huge capacity, while wisely keeping the old network for what it does best. Both strategies are valid for their context. We may well see both industries converging on a similar end state: heterogeneous networks where CAN and Ethernet coexist. The journey and timelines differ, but the end goal is the same: reliable, high-performance communication networks that can handle everything from tiny sensor readings to streaming video in vehicles and vessels of the future.
Comments are closed.