Table of Contents
Objective (why?)
Our project is called Commuter Emissions and the purpose is to track commuter emissions of employees/people of companies. This way, companies have access to a tool that allows them to easily view and analyze emission data and implement changes to help reduce their carbon footprint through methods such as carpooling. The motivation behind this project is that Scope 3 emissions aren’t highly regulated or enforced. As a result, it is difficult for companies to regulate their Scope 3 emissions themselves without any regulations. However, with this project, companies will be able to self-regulate and reduce their emissions on their own.
Background (who? where?)
The background of this project is currently oriented towards Stevens faculty and students as the participants in order to develop the project. As a result, the location of this project would also be Stevens and the surrounding area in a given radius. This circle area would be where faculty and students live and commute to work from. However, normally, the project would be targeted towards the employees of companies that choose to use this tool, and the location would be dependent on the location of the company and how far away its employees live.
Methodology (how? when?)
Our methodology encompasses three critical phases. The first phase will consist of data collection and analysis, data will be acquired from the Stevens Office of Sustainability. This data will be used to identify key commute patterns and trends amongst Stevens’ faculty and staff, ultimately creating a comprehensive dataset to be analyzed and provide context on the type of database to be used. The following phase would be Interactive Visualization Tool Development. It will involve the core planning and software development of the application. The software tools expected to be used will be JavaScript alongside the Google Directions and Mapbox APIs for dynamic route visuals, React for the front-end, and a Express.js server to communicate to our SQL or NoSQL database. The final visualization tool will have features like interactive maps, emission calculations, and alternative route suggestions. The final phase, Testing and Integration entails usability testing and feedback incorporation from both the Office of Sustainability and any other end-users. This will ensure the tool is refined, user-friendly, and ready for deployment. We plan on having the tool be developed efficiently while meeting the project’s objectives and serving as a valuable resource for understanding and analyzing commuting habits, their environmental impacts, and how an organization can work towards lowering their emissions.
Expected results (what?)
The expected results of this project will be a fully functioning website that will allow the user to input a ZIP Code and calculate the emission of commuters coming from that ZIP Code to campus using the data collected from the Google form that will be sent out to staff and students. Using the data produced by this website hopefully, Stevens will be able to implement a route via bus or shuttle that will escort staff and students to campus and reduce the amount of cars being used and in turn reduce commuter emissions. If we are given more time and resources the final outcome of this project would be marketing it to other major companies to help them see the routes their employees take to go to work and reduce their carbon footprint by allowing them to establish commuter routes.
Costs (how much will it cost?)
Currently, we aren’t expecting to use any money to establish a functioning prototype for the project. We are planning to use the Google developer tools to implement the Google Directions API into our website and that shouldn’t cost any money unless we go over the quota of around 50,000 reloads on the website. If the project progress goes beyond our current expectations we may need to invest some of our budget, upwards of $500, to buying dedicated servers that can run, process, and store data given to us by companies and institutions. However, we don’t expect our progress to go beyond as of right now and we will save our budget as we are only working with data from the Stevens Office of Sustainability and can easily use a free server service to process the amount of given data.
Generate problem statements that focus on the function to be achieved by any viable design solution
Scope 3 emissions are not highly regulated or enforced for companies, which makes it difficult to understand their environmental impact.
The lack of visibility on Scope 3 emissions makes it difficult for companies trying to become ecologically friendly to find ways to reduce their emissions.
2. Apply a number of techniques and strategies such as the statement-restatement technique, the source/cause approach, the revision method, present state-desired state (PS-DS) strategy, and Duncker diagrams
Statement-restatement
Organizations and Institutions do not provide adequate transportation for their employees, leading to more usage of vehicles to commute to work and therefore raising Scope 3 emissions that impact the environment.
Source/cause approach
Why-Why diagram
Revision method
Our current method will take collected data from Stevens staff and calculate Scope 3 emissions. However we can expand the developed web tool to be able to intake higher quantities of data from larger companies and help them calculate their Scope 3 emissions from their employees and ideally resolve that through solutions like carpooling or promoting the use of public transportation in high density areas.
Present state-desired state (PS-DS)
Present state companies are struggling in reducing their Scope 3 emissions or even calculating their Scope 3 emissions due to lack of data. Our desired state is providing a product that can help do both and ideally reduce their initial Scope 3 emissions through a multitude of possible solutions and insights.
Duncker diagrams
3. Perform Kepner-Tregoe (KT) situation analysis to evaluate various aspects of a situation in terms of three criteria (timing, trend, and impact), thereby determining what is known, which tasks should be performed, and in what order these tasks should be completed
In regards to the situation analysis of this problem, the timing is appropriate as there are currently not many regulations or enforcements surrounding Scope 3 emissions. In addition, the current trend of companies and governments becoming more environmentally friendly by reducing their carbon footprints further supports the timing of this problem and solution. In terms of the urgency and concern for this problem and solution, there is a moderate level as the issue is not one that will be detrimental in the short term if not solved, but is one that is receiving more attention as companies try harder to reduce their carbon footprint. Therefore, from this analysis, it is necessary to do research about commuter emissions as well as the various companies that would benefit from this tool. Then, it is necessary to learn about the different software available that are able to be utilized for this project and test them while getting feedback from users/companies. Finally, one of the final tasks would be to understand how this project could be expanded to other companies outside of just Stevens in different areas and evaluate if features need to be added or adjusted to compensate for the switch.
4. Perform KT problem analysis to determine possible causes of a problem
For the KT Problem Analysis phase, identification of the primary issue is that there is a lack of visibility and regulation regarding Scope 3 emissions, which is becoming a significant concern for companies striving to understand and mitigate their environmental impact. The cause of this predicament primarily lies in the absence of enforceable policies and comprehensive tools that track and manage these emissions effectively. This absence of insight into Scope 3 emissions is a global issue, but for our situation, we plan to observe at a small scale starting with the commuting practices of staff and faculty at Stevens Institute of Technology. Companies, both identified and not yet known, that are invested in achieving sustainability goals are the primary customers affected by this problem. Those not engaging with sustainability are not immediate customers nor affected by this issue. Information necessary for resolving this problem will likely be sourced from offices or individuals dedicated to sustainability within organizations, with others in these entities unlikely to offer relevant data. For instance the Stevens Offices with close connections to transportation and parking on campus can provide good information on such data. The problem has been persistently evolving in correlation with the growing emphasis on and commitment to sustainability by various organizations. Timing-wise, the problem is most relevant now, given the increasing number of companies aiming to decrease their carbon footprints. The problem’s magnitude is substantial, particularly for organizations keen on adopting sustainable practices but finding themselves hindered by a lack of data and strategies to reduce Scope 3 emissions.
Design each task in a problem-solving effort so that it is most fruitful and provides the most information or guidance
The first task in our problem-solving effort will be comprehensive data collection. The core functionality of our tool will be dependent on capturing essential data such as the commuter's zip code of origin, destination, and mode of transportation. This can be achieved systematically through surveys or user-friendly data entry interfaces. With our tool being web-based, designing an intuitive and comprehensive user interface in React would be our next task. While working on the application, it will be crucial we keep in mind the main objective to create a tool where users can easily input their organization's commuting details, comprehend said emissions results, and visually interpret their Scope 3 emissions contributions. To represent the commuting data visually, we will leverage the Mapbox API. We plan to focus our tasks on the precision and clarity of map pins alongside poly-lines to represent the routes between them. Furthermore, integrating the Google Map API's poly-line functionalities would be ideal for our purpose. The data will be scraped beforehand and saved in a database for efficient use of our API calls, and it will allow for ease of access from the web application. With a prototype in place one of the last tasks would be to get real-time user interaction as it will highlight potential improvements, allowing for refinement in design and functionality, ultimately culminating in a tool that's both robust and user-focused. After we get feedback we can iterate and improve upon the product from there.
Use various attributes of the final solution state to guide earlier decisions made along the solution path
The final solution state of this project is to produce a web application tool that can be used by any company to see how their workers commute to work. This way, they can see the amount of Scope 3 emissions that their company employees produce while commuting, enabling them to come up with ways to reduce these emissions through means such as carpooling. From this final solution state, this web application must be able to accurately display the commuter paths of each employee through a given dataset and to be able to calculate the amount of Scope 3 emissions from this. As a result, this means that in the early project decisions, it is necessary to ensure that the web application can take a given dataset and produce similar results. This is why our initial decisions for the project have been to use Stevens as a case study and analyze datasets of students and faculty members who commute to campus to ensure that our web application can produce the required information.
Define design goals and design specifications
The web application shall visualize polylines on a displayed map from given zip codes
The web application shall calculate the emission output based on modes of transportation
The web application shall intake data (through some form, ex. Excel), process it, output a result, and store it inside a database
The web application shall have an intuitive interface
The web application would be able to be used for other companies besides Stevens, which is serving as the case study
Eliminate paths that do not satisfy the desired design goals and/or specifications
Initially, when we were discussing possible avenues of design for this project, we had to consider the tech stack that we wanted to use for our web application. We wanted a tech stack that would be easy to implement components and APIs such as Mapbox, which led us to choose Typescript and Tailwind CSS instead of vanilla HTML, CSS, and Javascript. Furthermore, in considering the type of data that we would be receiving and storing, we determined that most of it would be non-relational. As a result, we are currently leaning more towards a noSQL type of database such as MongoDB rather than a SQL type as the data from commuters is not largely relational. In addition, the final project solution state requires that this project be usable by other companies besides our case study, Stevens, which requires us to consider different data inputs. Thus, the web application cannot be strictly designed for just Stevens but instead be modular enough to work for a company that chooses to use it.
Search and include relevant results of the proposed design for any of the following:
Note: There is no specific website that calculates the Scope 3 carbon emissions for commuters, but there are multiple existing websites that calculate carbon footprints for multiple categories
Trademarks (or service marks)
SAP is a company that develops enterprise applications for companies, the following is a list of trademarks for multiple categories such as software, methodology, applications, etc. The full list is available with the link provided.
Copyrights (or licenses)
As we will be relying on our own calculation of Scope 3 emissions, there are no copyright laws we would need to consider with the act of performing said calculation. However, our main copyright concerns would stem from the usage of third-party software to accomplish our web-based application.
Google Maps API Copyright and Terms:
Attribution rules state that the Google logo and copyright notices must always be prominently displayed when using the API.
Developers are not allowed to scrape or download data from Google Maps. Your usage of the Maps should be dynamic, meaning one must call their servers when you need the data rather than storing it.
There are exceptions to storing or caching retrieved data. In our case, caching polyline data to improve site efficiency via a database is allowed as long as the data is only cached for 30 days, it can be retrieved again after.
Users of the API cannot resell Google Maps data or services.
Any modification or distortion of the map results that misleads users is not allowed.
Mapbox API Copyright and Terms:
Similar to Google Maps, Mapbox requires that you provide proper attribution when using their maps. Typically, this comes in the form of a "© Mapbox" or "© OpenStreetMap" label on the map.
Mapbox's map data is derived from OpenStreetMap, and OpenStreetMap data is licensed under the Open Database License (ODbL). If our product contains a derived database using data from Mapbox directly, we would be required to offer that derived database under the ODbL, a relatively loose copyleft license related to databases.
Generally not allowed to cache or store Mapbox data, similar to the Google Terms of 30 days listed above.
Relevant software copyrights (won’t be directly interacted with but it is relevant to our project’s topic and scope):
Patents (or standards)
https://patents.google.com/patent/US7853436B2/en
This patent is for a system/method for tracking greenhouse gas emissions. It is able to record and report this emission information as well. More specifically the system is able to track the emission data for an enterprise by keeping track of information such as direct and indirect emission sources. This patent is similar to our proposed project of tracking Scope 3 emissions for companies but does not appear to consider Scope 3 emissions in their analysis and tracking of emission data.
https://patents.google.com/patent/US20210224819A1
This patent is for an approach that is able to track carbon footprints by calculating the carbon emissions for a product, then finding products that are similar and providing their carbon emissions as well. This patent is similar to our proposed project of tracking Scope 3 emissions as each product has its lifecycle tracked in order to calculate the emissions that they produce. Similar to our proposed project we track each commuter’s path to their company through various means of transportation such as car, train, or bus.
1. System Model
2. Process models
Input data
Calculate data
Store data
8.1. Ethical issues: identify any potential hazards in the proposed design, e.g., foreseeable misuses
Since we are asking our customers to input their data into our tool and we are storing this data in a server to output it back to the customer whenever they want, depending on who has ownership of this tool this data can easily be taken and sold which would be incredibly dangerous as it has the companies and employee's data
If a company's data is open to the public any person can input that data into the tool to calculate that company's Scope-3 emissions and make that data available to whoever they want against the company's wishes
Since the tool completely relies on the user to input data companies can potentially input incorrect data to produce inaccurate and misleading results to boast about their emission output which can be misleading to consumers
An ethical issue with using this tool would be the lack of action after receiving the results, if a company is greatly above the Scope-3 emissions output and knows this after using this tool yet still chooses to do nothing about it would be a misuse
9.1. Ethical issues: provide solutions to eliminate hazards identified in Assignment 8.1, e.g., foreseeable misuses
To protect the data inputted by users and stored on our servers we can encrypt the data, only allow authorized users to access the data, or require more than 1 authorized user to be able to access the data
To protect people from potentially misusing their data we can implement user authentication as well as create legal agreements to deter people from using another entity’s data without their permission
To prevent companies from purposely inputting wrong and misleading data we can implement software to routinely check the inputted information and flag potentially incorrect or unrealistic data that can be analyzed further
To encourage and promote companies following the solutions we provide to reduce carbon emissions we can promote them on our website and boast about their carbon emission reduction efforts
8.2. Product liability: identify any potential hazards in the proposed design, e.g., changes that may occur during the useful lifetime
The web application's handling of sensitive data including employee commute details and company emissions data presents a risk of data breaches or unauthorized access, potentially compromising both company and employee privacy.
Inaccurate emissions calculations could result from incorrect data provided from the user, leading to misinformed decisions about environmental impact.
There's a risk of system outages or failures over the application’s lifetime, which can affect companies’ ability to access emissions data, impacting compliance reporting and decision-making processes.
Dependence on third-party APIs like Mapbox and Google Maps for critical functionalities may lead to disruptions in service if these APIs experience downtime or change their policies.
9.2. Product liability: provide solutions to eliminate hazards identified in Assignment 8.2, e.g., changes that may occur during the useful lifetime
We can implement encrypted data transmission, have a secure server architecture, and plan to have regular security audits, alongside strict access controls and authentication processes to safeguard sensitive data.
Incorporate data validation checks and guidelines within the application to identify and flag potentially inaccurate data entries, reducing the risk of user errors in emissions calculations.
We can also establish a routine maintenance schedule and a reliable data backup system to prevent data loss and ensure continuity in case of system failures, maintaining uninterrupted access to emissions data.
Develop contingency plans for API dependency, such as having backup APIs or a local version of critical functionalities, to ensure service continuity in case of third-party API disruptions or policy changes.
8.3. Social impact: identify any potential hazards in the proposed design, e.g., disposal after the useful life has ended
Since this project offers companies that use it an advantage when it comes to reducing their Scope 3 emissions by their commuters, it may not be as accessible for smaller companies that cannot afford the software if it costs money. Thus, increasing the divide between small and large companies in terms of activeness in reducing environmental impact.
Company data such as their employees' information, commute routes, or zip codes would have to be deleted in order to protect them from blackmail from malicious sources or exposure to the public.
Since the proposed web app is almost entirely digital in its design, it could lead to the accumulation of software resources that get replaced by newer ones. This could lead to software bloat or inefficiency in resource allocation if older/deprecated software is not properly disposed of.
9.3. Social impact: provide solutions to eliminate hazards identified in Assignment 8.3, e.g., disposal after the useful life has ended
Offer the project to all companies at an equal cost to each. For instance, a large company would get charged more as it has more employees whose Scope 3 emissions would need to be tracked while a small company would not be charged as much with their smaller amount of employees. Another potential solution to this would be to simply offer the software for free to all companies so they can all equally utilize it at their choosing.
Implement a safe way to safely purge or delete employee/company information from the database in the event that the software is no longer utilized after a long period of time, the company no longer needs it, or the software becomes obsolete to another in the future. This implementation could also allow companies to search for data to ensure that it was properly deleted or notify them if data/information has been idle in the database for a long period of time.
Regularly update the web app to ensure that the most current or efficient systems are being utilized, and convert to them if necessary. During conversion, transfer data and remove/delete old systems or software in order to prevent software bloat and reduce resource allocation if not needed.
*Since all of our group members are already all apart of the same senior design team, we are basing the plan off of what we’ve done/planned so far in our senior design
Tentative Senior Design Plan
Fall 2023 Semester
Conducted brainstorming sessions to refine project’s goal of visualizing emissions while establishing key stakeholders and acceptance criteria
Established Stevens Office of Sustainability as the primary case study for the project’s scope
Confirmed algorithm for emission calculations so that we know what data we need to request from the API
Established weekly meeting schedule for the technical team as well as established biweekly meetings with our Faculty Advisor to convey progress and expectations
Meet with the department of sustainability at Stevens to see if any data is available and what requirements they have of our project as they are serving as a type of stakeholder
Complete Concept Design Presentation and Report
Development work
Weigh options and analyzed requirements to decide to use the MERN stack
Explored technical requirements for storing route data and converting into polylines for the visualization
Created Github repository as well as Github project board for keeping track of tasks and implementing an agile workflow
Developed simple frontend to display dummy routes
Created backend architecture to request route data from Google Maps APIs based on different zip codes that the frontend requests
Ported over 75% of previous vanilla implementation into React
Initial budget / Anticipated Costs
Based on the proposed tech stack and APIs, we expect to be able to use the free hosting options for our full-stack web application as well as the free storage plan provided by MongoDB. The only costs that we expect our project to incur are from the API calls from the Google Cloud Developer Platform. However, since the pricing for each API call is very low at about $0.005 and we will not require a large number of calls for each ZIP code, the total cost will be estimated to be under $50.
Complete Preliminary Design Presentation and Report
Spring 2024 Semester
Additional Development
Complete planning of User Interface for displaying routes, infographics, and actionable advice.
Implement the ability to display multiple polylines on Mapbox.
Finalize the API calls from Google Maps Service to get the necessary data for calculations and polylines.
Set up how the emissions will be calculated.
Connect the backend with the MongoDB database we will be using.
Have graphics of the data and solutions be outputted on the webpage in tandem with the map.
Security features to keep user data safe.
Prototyping / Testing
Test service against real user data displaying routes and receiving analysis; compare against success criteria
Use data provided to us by the Stevens Office of Sustainability through their Google form sent to staff and students.
After hosting the alpha prototype, send it out to various stakeholders such as Luke Hansen from the office of sustainability and Professor Odonkar for testing and feedback.
Implement feedback to prepare to develop a beta prototype for further testing.
Preparation for Senior Expo
Prepare presentation slides/posters to explain the methodology of developing our solution and why.
Have TV screens to display demos to viewers.
Appropriate business attire amongst team members.
Have strong data and statistics to back our solution.