66 results found

1. Are there any restrictions on integrating IoT devices from multiple manufacturers to enable AI-driven predictive maintenance, real-time moni

   Our system integrates IoT devices from multiple manufacturers to collect vehicle telematics, including data from OBD2, J1708, J1939, GPS, G-sensors, and voltage references. This data is processed using an AI-driven framework, where a large language model (LLM) is trained on specific datasets to assist in real-world actions and service decisions. The AI analyzes telematics data alongside historical maintenance records, factory service schedules, fluid analysis, and real-world insights from mechanics and fleet managers. This enables predictive maintenance, driver behavior monitoring, and condition-based service scheduling. The system integrates these insights into fleet management operations, facilitating onsite repairs, in-house maintenance, or third-party service coordination based on data-driven recommendations.

   Our system integrates IoT devices from multiple manufacturers to collect vehicle telematics, including data from OBD2, J1708, J1939, GPS, G-sensors, and voltage references. This data is processed using an AI-driven framework, where a large language model (LLM) is trained on specific datasets to assist in real-world actions and service decisions. The AI analyzes telematics data alongside historical maintenance records, factory service schedules, fluid analysis, and real-world insights from mechanics and fleet managers. This enables predictive maintenance, driver behavior monitoring, and condition-based service scheduling. The system integrates these insights into fleet management operations, facilitating onsite repairs, in-house maintenance, or third-party service… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-FT1: Exploring AI-based Predictive Maintenance for Public Transit Fleets  ·  Delete…  ·  Admin →

2. Ground hazards to be determined only from existing data?

   Is the development of sensor systems (e.g. ground movement detection sensors) in scope for this topic? Or is this topic intended to analyze data only from existing data sources?

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-FR3: Railroad Ground Hazard Mitigation Technology  ·  Delete…  ·  Admin →

3. Does NHTSA recommend or suggest that we collaborate with other small businesses or universities?
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

4. What specific system requirements do law enforcement agencies have that we must explore in our feasibility study to achieve optimum success?
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

5. Does NHTSA have a set of standards and API specifications for sharing data with CRSS?
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

6. "This funding opportunity is specific to automated crash reporting software."

   Hello! We noticed the following statement in a response provided to another posted question:

   "Thank you for your question. This funding opportunity is specific to automated crash reporting software."

   This response sparked some additional questions to us. We would love to ask for additional explanation about the government's desired mechanics and movement of data. Here is some elaboration:

   1. ACN (Automated Crash Notification) data are contained within NEMSIS and other data systems.

   2. However, they are not USER-mediated (indeed, they are called "automated"). Rather, the data are generated by a signal from the vehicle (i.e., OnStar) or in more recent variants, by a phone or similar (i.e., Android or iPhone crash notification, Cambridge Mobile Telematics, Samsara "harsh event notification," etc.).

   3. By contrast, as we asked elsewhere, the topic states that one of its goals is to reduce documentation burden on Responders (specifically indicated as LEAs, but we assume that the same safety consideration applies to Fire and EMS providers):

   "Completing the forms may take a significant portion of the officer’s time, which may lead to poor quality data as the officer may rush or not have enough time to complete their task. NHTSA is mindful of officer roadway exposure to secondary crashes and inaccuracies in data collection and looks for ways to reduce risk while improving data quality." (Page 26)

   1. In older vehicles where ACN data must be collected via OBDII port or similar physical connection, there is no reasonable way for an LEA to collect such data in real-time on the road; doing so requires cables and computers. In newer vehicles, such data can "burst" from the vehicle and be captured within, for example, a NEMSIS v3 electronic patient care report using an app or other software.

   ---

   THEREFORE: We wish to understand the government's goal with regards to capturing ACN and other data and using them together with (or distinct from) existing data sets like MMUCC, NEMSIS, NFIRS/NERIS, FARS, FIRST, etc.:

   -- A. Is the goal to create a NEW dataset that is separate from the other data system mentioned above, and adds some additional dimension(s) of insight that they do not provide?

   A2. If yes, then what insights does the government feel are MISSING from the existing data sets, such that an entirely new one is required?

   --

   B. Is the goal to create an integration engine that can ingest data in any/all of the formats listed mentioned, align them, provide a cross-walk for decision-making, then be able to pushing data back out to software systems that use one of the existing data standards?

   --

   C. If this project is LIMITED TO ACN -- as was stated in the aforementioned Q&A response -- yet ACN data already exists in NEMSIS, why are the NEMSIS data insufficient (particularly if they were to be aligned with MMUCC and others, as noted in #B above)?

   --

   D. IF THIS PROJECT IS LIMITED TO ACN TECHNOLOGY, then is it also geared toward firms (such as those listed above) which provide ACN software today but whose data do not currently interoperate with the other existing data standards? (Why do they not currently interoperate?)

   --

   E. Would it align with the topic for a company that specializes in NEMSIS data and interoperability -- and which therefore currently collects, aggregates, converts, aligns, and distributes ACN data on-demand (when available), but does not PRODUCE ACN data itself (because that is what the vehicle is responsible for generating) -- to propose to interoperate the existing data with MMUCC, FIRST, FARS, etc.?

   Thank you so much!

   Hello! We noticed the following statement in a response provided to another posted question:

   "Thank you for your question. This funding opportunity is specific to automated crash reporting software."

   This response sparked some additional questions to us. We would love to ask for additional explanation about the government's desired mechanics and movement of data. Here is some elaboration:

   1. ACN (Automated Crash Notification) data are contained within NEMSIS and other data systems.

   2. However, they are not USER-mediated (indeed, they are called "automated"). Rather, the data are generated by a signal from the vehicle (i.e., OnStar) or in more recent variants, by… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

7. What existing integration approaches are currently in use at NHTSA CRSS?
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

8. 1. What are some significant data types that crash data collection and analysis may require to benefit modernized crash report sampling syst
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

9. What are some significant data types that crash data collection and analysis may require to benefit modernized crash report sampling syst
   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

10. Two questions on EOT/HOT device desired requirements

    Two questions on the EOT/HOT technology, current and projected:

    1) How much data is communicated between EOT and HOT devices? Is there anticipated increase in the amount of data to be communicated with next gen EOT and HOT devices?

    2) What is the allowable service interval for proposed EOT devices (including, but not limited to, battery replacement)?

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FR2: Development of Next Gen End of Train Device Technology  ·  Delete…  ·  Admin →

11. Should the system be portable (easy to install/remove/transport), or will it be installed in a simulator or engine long term?
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FR4: Human Factors Fatigue Assessment System  ·  Delete…  ·  Admin →

12. Can the system be powered from outlets, or does it need to be battery powered?

    If battery powered, is there a required run-time?

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FR4: Human Factors Fatigue Assessment System  ·  Delete…  ·  Admin →

13. Are there any behavioral indicators of fatigue that you do not want to see incorporated in a solution?
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FR4: Human Factors Fatigue Assessment System  ·  Delete…  ·  Admin →

14. Do you have a preferred existing standardized measure of fatigue we should use for validation?
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FR4: Human Factors Fatigue Assessment System  ·  Delete…  ·  Admin →

15. Is this topic limited to predictive maintenance for vehicles that comprise transit fleets?

    Will you consider topics exploring AI-based predictive maintenance that also considers public transit guideways/railways as well as vehicle fleets?

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FT1: Exploring AI-based Predictive Maintenance for Public Transit Fleets  ·  Delete…  ·  Admin →

16. Using / integrating existing standards into one place only -- or creating a new overarching "superset" that feeds into other systems?

    The topic references myriad datasets and associated tools, including:

    1. MMUCC
    2. FIRST
    3. FARS
    4. NEMSIS (by reference, since it is contained within MMUCC)
    5. Trauma registry (by reference, since it is contained within MMUCC)
    6. NFIRS/NERIS (when fire services respond to crashes)
    7. EMS UUID (by reference, since it is contained within MMUCC)

    Is the goal of this topic to create a "master" dataset that can overarch all of the above (and possibly others), superseding them with the goal of "enabling LEAs to increase accuracy, timeliness, completeness, and uniformity of crash reports through the reduction of missing data and coding errors" -- presumably through fast and efficient charting in the field, at the crash scene? (The reference to speed and efficiency is drawn from the goal to "reduce police officer exposure to secondary crashes.") (PG. 26)

    OR

    Is the goal NOT to create a new dataset but to crosswalk and synthesize several EXISTING datasets, turning them into "one report that rules them all"?

    Begging forgiveness for my Lord of the Rings reference (!!!): is the goal a landing point for data from several different data sets and systems that operate within separate spheres, so they can come together and form a single picture of the scene and situation?

    OR

    A single "master" software that can capture data that has a landing point within each of the other data sets, then distribute the approach data across those datasets to their respective landing points (e.g., to NEMSIS, or NERIS, or FARS, or FIRST, etc., however is appropriate)?

    (Or both?)

    The topic references myriad datasets and associated tools, including:

    1. MMUCC
    2. FIRST
    3. FARS
    4. NEMSIS (by reference, since it is contained within MMUCC)
    5. Trauma registry (by reference, since it is contained within MMUCC)
    6. NFIRS/NERIS (when fire services respond to crashes)
    7. EMS UUID (by reference, since it is contained within MMUCC)

    Is the goal of this topic to create a "master" dataset that can overarch all of the above (and possibly others), superseding them with the goal of "enabling LEAs to increase accuracy, timeliness, completeness, and uniformity of crash reports through the reduction of missing data and coding errors" -- presumably through fast… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →

17. What kind of surfaces will these modular lane dividers be installed on? (e.g.asphalt, pavers, concrete)
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FH2: Modular Construction of Protected Intersection and Turbo Roundabout  ·  Delete…  ·  Admin →

18. What are the standard methods to measure the strength of the lane dividers material mentioned in the document?
    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FH2: Modular Construction of Protected Intersection and Turbo Roundabout  ·  Delete…  ·  Admin →

19. What are the fixation types allowed?

    Regarding fastening systems, are there any restrictions (other than being used on the road pavement) or recommendations?

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-FH2: Modular Construction of Protected Intersection and Turbo Roundabout  ·  Delete…  ·  Admin →

20. New data CREATION software vs. INTEGRATION software (that incorporates many existing datasets)?

    In reviewing this topic area in detail, we have one key question: There is reference, both explicitly and implicitly, to several separate federal datasets.

    (By implicit, we mean that -- for example -- the MMUCC 6th Edition guidelines specifically reference NEMSIS several times, so even though this topic does not reference NEMSIS, it is clearly a part of the process. In many communities, fire services also respond to roadway crashes, and the new US Fire Administration National Emergency Response Information System (NERIS) standard references NEMSIS as well, so there is a demonstrable overlap among the standards used by various responding agency types.)

    There are references within the topic to "must collect and integrate...data elements at the crash, vehicle, and person level," etc. But in other places within the topic, it says "this project aims to develop software with automation features and capabilities that integrates into current crash report software."

    In short, the topic acknowledges that there are SEVERAL different software systems currently used by LEAs -- and other Responders to crash scenes, including Fire and EMS, plus trauma registries, each of which uses separate software. There are concurrent / parallel federal initiatives ongoing now to integrate and cross-talk those software systems. The topic acknowledges this as well: "gather more robust data, crash reports should be accurate, complete, uniform, timely, accessible to users of data, and in a format that supports data integration with other data and systems."

    That said, is the goal of this topic to create a data COLLECTION software (i.e., primary or new data that will be first entered into the software system that results from this topic) -- or is the goal to create INTEGRATION software that pulls together lots of existing data into a unified repository (for lack of a better term) where it can be cross-walked, collated and evaluated side-by-side for decision-making?

    In reviewing this topic area in detail, we have one key question: There is reference, both explicitly and implicitly, to several separate federal datasets.

    (By implicit, we mean that -- for example -- the MMUCC 6th Edition guidelines specifically reference NEMSIS several times, so even though this topic does not reference NEMSIS, it is clearly a part of the process. In many communities, fire services also respond to roadway crashes, and the new US Fire Administration National Emergency Response Information System (NERIS) standard references NEMSIS as well, so there is a demonstrable overlap among the standards used by various responding… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  25-NH1: Automated Police Crash Report Data Collection and Management Software  ·  Delete…  ·  Admin →