SMRT: Waste Segregation System for

Recyclable and Non- Recyclable Waste

System Design Document
Version 1
06/06/2024
CMS XLC Table of Contents

Table of Contents
1. Introduction............................................................................................................... 2
1.1 Purpose of the SDD................................................................................................................3
2. General Overview and Design Guidelines/Approach............................................3
2.1 General Overview..................................................................................................................4
2.2 Assumptions/Constraints/Risks..............................................................................................5
2.2.1 Assumptions...................................................................................................................5
2.2.2 Constraints......................................................................................................................5
2.2.3 Risks...............................................................................................................................6
2.3 Alignment with Federal Enterprise Architecture...................................................................7
3. Design Considerations.............................................................................................7
3.1 Goals and Guideline...............................................................................................................8
3.2 Development Methods & Contingencies...............................................................................8
3.3 Architectural Strategies..........................................................................................................9
Key Design Decisions and Strategies........................................................................................10
3.4 Performance Engineering.....................................................................................................11
Incorporation of Performance Requirements.............................................................................12
4. System Architecture and Architecture Design.....................................................12
4.1 Logical View........................................................................................................................14
4.2 Hardware Architecture.........................................................................................................15
4.2.1 Performance Hardware Architecture............................................................................18
4.3 Software Architecture..........................................................................................................18
4.3.1 Performance Software Architecture.............................................................................21
Single Points of Failure..........................................................................................................21
4.4 Information Architecture......................................................................................................22
4.4.1 Records Management...................................................................................................23
Description of Data Sources..................................................................................................23
4.5 Internal Communications Architecture................................................................................25
4.6 System Architecture Diagram..............................................................................................26
5. System Design........................................................................................................ 26
5.1 Business Requirement..........................................................................................................27
5.2 Database Design...................................................................................................................27
The database design for the SMRT Waste Segregation System encompasses various tables to
store data related to waste items, classifications, system logs, configuration settings, and
performance metrics. Here's a summary of the database schema:.................................27
5.2.1 Data Objects and Resultant Data Structures................................................................27
Functions................................................................................................................................28
5.2.2 File and Database Structures........................................................................................28
5.3 Data Conversion...................................................................................................................31
5.4 User Machine-Readable Interface........................................................................................32
5.4.1 Inputs............................................................................................................................33
5.4.2 Outputs.........................................................................................................................33
SDD Version X.X ii <Project and release name>
CMS XLC Table of Contents

5.5 User Interface Design...........................................................................................................34

5.5.1 Section 508 Compliance..............................................................................................34
6. Operational Scenarios............................................................................................34
Operational Scenarios............................................................................................................35
7. Detailed Design....................................................................................................... 35
Hardware Component Integration:........................................................................................36
Software Component Integration:..........................................................................................36
Hardware-Software Integration:............................................................................................36
COTS Package Integration:...................................................................................................36
7.1 Hardware Detailed Design...................................................................................................37
7.2 Software Detailed Design....................................................................................................37
7.3 Security Detailed Design......................................................................................................39
N/A 39
7.4 Performance Detailed Design..............................................................................................39
7.5 Internal Communications Detailed Design..........................................................................39
8. System Integrity Controls...................................................................................... 40
9. External Interfaces..................................................................................................41
9.1 Interface Architecture...........................................................................................................42
9.2 Interface Detailed Design..............................................................................................42
Appendix A: Record of Changes................................................................................42
Appendix B: Acronyms................................................................................................43
Appendix C: Glossary..................................................................................................44
Appendix D: Referenced Documents.........................................................................45
Appendix E: Approvals................................................................................................46
Appendix F: Additional Appendices...........................................................................47
Appendix G: Notes to the Author/Template Instructions.........................................48

List of Figures
No table of figures entries found.

List of Tables
Table 1 - Record of Changes.........................................................................................................19
SDD Version X.X iii <Project and release name>
CMS XLC Table of Contents

Table 2 - Acronyms.......................................................................................................................20
Table 3 - Glossary..........................................................................................................................21
Table 4 - Referenced Documents...................................................................................................22
Table 5 - Approvals........................................................................................................................23

SDD Version X.X iv <Project and release name>

CMS XLC Introduction

1. Introduction
The SMRT project aims to address the critical issue of waste management by implementing an
automated Waste Segregation System for Recyclable and Non-Recyclable Waste. This System Design
Document (SDD) serves as a comprehensive guide outlining the technical specifications, architecture,
and expected evolution of the SMRT system.
This System Design Document not only serves as a detailed blueprint for the development and
implementation of the SMRT system but also provides comprehensive insights into its architecture,
functionality, and anticipated evolution over time. By elucidating the intricate interplay of sensors, and
intelligent algorithms, it delineates the system's operational framework with meticulous detail.
Furthermore, it offers a roadmap for future enhancements and refinements, ensuring that the SMRT
system remains adaptable and responsive to evolving waste management challenges and technological
advancements.

1.1 Purpose of the SDD

The purpose of this System Design Document (SDD) is to provide a comprehensive and detailed
blueprint for the development and implementation of the SMRT Waste Segregation System for Recyclable
and Non-Recyclable Waste. Tailored specifically to the needs of the SMRT project, this document serves
as a guiding framework for engineers, developers, and stakeholders involved in the creation of the
automated waste segregation system.

The SDD outlines the architectural design, functional specifications, and expected evolution of the
SMRT system, ensuring clarity and alignment with project objectives. By understanding the system's
components, interactions, and technical requirements, it facilitates effective communication among team
members and stakeholders, fostering a shared understanding of the project's scope and deliverables.

SDD Version X.X 1 <Project and release name>

CMS XLC General Overview and Design Guidelines/Approach

2. General Overview and Design Guidelines/Approach

This section describes the principles and strategies to be used as guidelines when designing and
implementing the system.

2.1 General Overview

The SMRT Waste Segregation System for Recyclable and Non-Recyclable Waste is designed to
revolutionize waste management through automation and advanced technology. The system operates
within waste management facilities, cities, and environmental agencies working to improve waste
sorting and recycling efforts.
The basic design approach employs a combination of sensor technology, machine learning
algorithms to automate the segregation process. The overarching goal is to streamline waste sorting,
minimize contamination, and maximize recycling rates, contributing to a more sustainable and
environmentally friendly waste management.
Software Architecture:
1. Arduino CC: The software architecture involves utilizing the Arduino CC environment for
programming the Arduino UNO microcontroller board. This includes writing code to control the
sensors, motors, and other components connected to the Arduino UNO.
2. PyCharm and VS Code: These Integrated Development Environments (IDEs) may be used for
developing software components that run on the central processing unit (CPU) or other computing
devices integrated into the system. PyCharm is particularly useful for developing Python scripts,
while VS Code provides a versatile platform for various programming languages and extensions.

System Architecture:

1. Raspberry Pi: The Raspberry Pi serves as the central processing unit (CPU) of the system. It
coordinates the operation of various components, processes data from sensors, and controls the
sorting mechanism. Additionally, it may host software applications for data analysis, and
communication with external systems.

2. Arduino UNO: The Arduino UNO microcontroller board is responsible for interfacing with
hardware components such as the ultrasonic sensor, stepper motor, and L293D motor driver. It
executes control algorithms, reads sensor data, and sends commands to actuate motors and other
actuators.

3. L293D Motor Driver: The L293D motor driver facilitates the control of DC motors used in the waste
segregation system. It receives signals from the Arduino UNO and provides the necessary power and
direction control to drive the motors responsible for sorting waste items.

4. Ultrasonic Sensor and Camera: These sensors capture data about the waste items passing through the
system. The ultrasonic sensor measures distance and detects the presence of objects, while the
camera captures images for visual analysis and classification.

5. Stepper Motor: The stepper motor is employed for precise movement in application. It is controlled
by the Arduino UNO to ensure accurate and consistent operation of the sorting mechanism.

6. PCB, Wires, Angle Bar, Metal Sheet, Rivets, Screws: These components are part of the physical
structure and assembly of the waste segregation system. The PCB may host electronic components
and facilitate connections between sensors, actuators, and the microcontroller.

7. Power Supply: The power supply provides electrical power to all components of the system,
SDD Version X.X 2 <Project and release name>
CMS XLC General Overview and Design Guidelines/Approach

ensuring proper operation and functionality.

8. Soldering Iron and Soldering Lead: These tools are used for soldering connections between
electronic components, ensuring reliable electrical connections and signal transmission .

2.2 Assumptions/Constraints/Risks
2.2.1 Assumptions

 Hardware Compatibility: The assumption is made that all hardware components listed in the system
architecture section are compatible with each other and can be integrated seamlessly. This includes
ensuring that the Raspberry Pi, Arduino UNO, sensors, motors, and other electronic components can
communicate effectively and function as intended.

 Software Compatibility: It is assumed that the software tools and environments mentioned, such as
Arduino CC, PyCharm, and VS Code, are compatible with the operating systems (OS) used for
development and deployment. This may include compatibility with Linux for Raspberry Pi,
Windows, or macOS for development environments.

 End-User Characteristics: The system is designed with the assumption that end-users have a basic
understanding of waste management principles and are capable of operating and maintaining the
system with minimal training. However, additional user training or documentation may be required
to ensure smooth adoption and usage of the system.

 Possible Changes in Functionality: There is a possibility that the functionality of the system may
need to be modified or expanded in the future to accommodate changes in waste management
regulations, technological advancements, or user requirements. Assumptions are made that the
system architecture and design are flexible and modular enough to accommodate such changes with
minimal disruption to operations.

 Maintenance and Support: It is assumed that the necessary resources and infrastructure for system
maintenance, including software updates, hardware repairs, and technical support, are available to
ensure the long-term viability and reliability of the waste segregation system.

2.2.2 Constraints

 Hardware or Software Environment: The system's design is constrained by the hardware and
software environments available for development and deployment. This includes limitations imposed
by the processing power, memory, and storage capacity of the Raspberry Pi and Arduino UNO
microcontroller. Additionally, compatibility issues with certain sensors, actuators, or communication
protocols may impact the system's design and functionality.

 Interoperability Requirements: The system must be capable of interoperating with existing waste
management systems, databases, and communication protocols. Ensuring compatibility and seamless
integration with external systems is crucial for the system's effectiveness and adoption.

SDD Version X.X 3 <Project and release name>

CMS XLC General Overview and Design Guidelines/Approach

 Performance Requirements: The system's performance must meet specified requirements for
speed, accuracy, and reliability. This includes ensuring timely detection and sorting of waste items,
minimal downtime, and efficient resource utilization to optimize energy consumption and
operational costs.

 Verification and Validation Requirements: Adequate testing and validation procedures are
necessary to verify the functionality, reliability, and safety of the system. Constraints related to
resource availability, time, and budget may impact the extent and thoroughness of testing, potentially
compromising the system's quality and reliability.

 Memory or Capacity Limitations: The limited memory and storage capacity of the hardware
components may impose constraints on the size and complexity of software applications and datasets
that can be processed and stored. Optimization techniques and data compression methods may be
required to mitigate these limitations and maximize system efficiency.

SDD Version X.X 4 <Project and release name>

CMS XLC General Overview and Design Guidelines/Approach

2.2.3 Risks
 Hardware Failure: The risk of hardware components, such as sensors, motors, or microcontrollers,
failing during operation could lead to system downtime and disruption of waste segregation
processes.
 Resource Constraints: Limited resources, such as budget or manpower, could affect the system's
development, deployment, and maintenance.

2.3 Alignment with Federal Enterprise Architecture

 Performance Reference Model (PRM):

 The SMRT system aims to improve waste management efficiency and effectiveness,
aligning with the PRM's focus on achieving desired outcomes.
 Performance metrics such as waste diversion rates, processing times, and system uptime can
be tracked to measure system performance against established goals.

 Business Reference Model (BRM):

 The system aligns with BRM by addressing a specific business function: waste management.
It supports activities related to waste collection, segregation, and recycling, contributing to
improved environmental stewardship and resource utilization.
 The BRM's Service Component Reference Model (SRM) can be leveraged to identify
reusable service components within the system architecture, promoting interoperability and
cost savings.

 Data Reference Model (DRM):

 The SMRT system collects and processes data on waste composition, user behavior, and
system performance. It adheres to DRM standards for data categorization, sharing, and
interoperability.
 Data exchange standards such as XML or JSON may be utilized for seamless integration
with other government systems or external data sources.

 Application Reference Model (ARM):

 The system's architecture and components align with ARM principles for modularization,
standardization, and interoperability. It may consist of layers such as sensors, actuators, data
processing units, following established architectural patterns.
 Compliance with ARM standards facilitates scalability, maintainability, and future
enhancements of the system.

 Technology Reference Model (TRM):

 The SMRT system leverages emerging technologies such as IoT sensors, machine learning
algorithms, and cloud computing infrastructure. It aligns with TRM guidelines for the
adoption of innovative IT solutions to address business needs.
 Open standards and protocols are utilized to ensure compatibility with existing and future
technology platforms, minimizing vendor lock-in and promoting flexibility.

SDD Version X.X 5 <Project and release name>

 CMS XLC Design Considerations

3. Design Considerations
Functionality and Purpose:
1. Intended Use: The waste segregation system will be used to dispose of garbage by
separating it into categories such as recyclable and non-recyclable waste.
2. Primary Task: Segregate waste materials such as recyclable and non-recyclable materials.
Ergonomics and Human Interaction:
1. User Demographics: Anyone
2. Interaction Points: Easy to use trash bin and ergonomic design.
Scalability and Adaptability:
1. Modular Design: Ability to segregate waste materials.
2. Future Updates: The system will recognize more waste materials.

3.1 Goals and Guideline

Goals:
Maximize Recycling Rates:
Increase the amount of waste diverted from landfills by improving the separation of recyclable
materials.
Reduce Environmental Impact:
Minimize the environmental footprint of waste by encouraging proper disposal and recycling
practices.
Enhance User Participation:
Make the system easy to use to encourage widespread adoption and compliance among users.
Improve Waste Management Efficiency:
Streamline waste collection, sorting, and processing operations to reduce costs and improve
efficiency.
Promote Environmental Awareness:
Educate the community on the importance of waste segregation and recycling to foster a culture of
sustainability.

Guidelines
Clear Categorization:
Recyclable Waste: Paper, cardboard, plastics (1-7), glass, metals, and certain electronic waste.
Non-Recyclable Waste: Food waste, contaminated materials (soiled paper, plastic), hazardous waste,
and non-recyclable plastics.
Bin Placement and Accessibility:
Place bins in convenient and easy to reach areas to encourage use.
Ensure bins are accessible to all users, including those with disabilities.
Regular Monitoring and Maintenance:
Implement a schedule for regular collection and emptying of bins to prevent overflow.
Inspect bins and surrounding areas to ensure cleanliness and address any issues promptly.

3.2 Development Methods & Contingencies

Development Methods:
Needs Assessment and Planning:
Stakeholder Engagement: Involve key stakeholders such as local authorities, waste management
companies, and community representatives in the planning process.
Goals Setting: Define clear objectives and performance metrics for the waste segregation system.
System Design:
SDD Version X.X 6 <Project and release name>
 CMS XLC Design Considerations

Categorization: Define categories for recyclable and non-recyclable waste.

Bin Placement: Strategically place bins in accessible and easy to reach areas.
Education and Training:
Awareness Campaigns: Run educational campaigns to inform the community about the importance
of waste segregation and how to use the system.
Training Programs: Provide training for waste management staff and community members on proper
segregation practices.
Contingencies:
Low Participation Rates:
Issue: Low community engagement and participation in waste segregation.
Contingency: Increase awareness campaigns, provide incentives for participation, and engage
community leaders to promote the system.
Financial Constraints:
Issue: Budget limitations affecting the implementation and maintenance of the system.
Contingency: Seek alternative funding sources such as grants, partnerships with private companies,
and community fundraising efforts.
Technical Issues:
Issue: Problems with bin functionality, durability, or placement.
Contingency: Conduct regular maintenance checks, replace faulty equipment promptly, and adjust
bin placement based on usage patterns.

SDD Version X.X 7 <Project and release name>

 CMS XLC Design Considerations

3.3 Architectural Strategies

Key Design Decisions and Strategies

The design of the SMRT Waste Segregation System incorporates several strategic decisions to
ensure the system's efficiency, scalability, and compliance with standards. Below are the major
architectural strategies and the reasoning behind each decision:

Microservices Architecture

 Decision: The SMRT system will be built using a microservices architecture.

 Reasoning: This allows for modular development, scalability, and easier maintenance.
Each microservice can handle specific tasks such as sensor data processing and database
management.
 Trade-offs: Microservices add complexity in deployment and communication between
services, but the benefits of scalability and independent development outweigh these
concerns.
 CMS EA Compliance: Aligns with CMS's emphasis on modularity and service-oriented
architecture.

Programming Languages and Frameworks

 Decision: Use Python for sensor data processing and control logic, Node.js for the
backend API, and React for the frontend.
 Reasoning: Python is simple and has strong support for machine learning libraries,
essential for the system's intelligent algorithms. Node.js offers a non-blocking I/O model
ideal for real-time applications and React provides a robust framework for dynamic user
interfaces.
 Trade-offs: Using multiple programming languages requires a team with diverse skills and
introduces complexity in integration, but it leverages the strengths of each language in its
domain.
 CMS EA Compliance: Python and JavaScript (Node.js and React) are commonly accepted
and align with standard practices.

Reuse of Existing Software Components

 Decision: Integrate existing open-source libraries for machine learning (TensorFlow),

sensor integration.
 Reasoning: Reusing proven libraries speeds up development and ensures reliability.
 Trade-offs: Dependence on third-party libraries requires vigilance regarding updates and
security vulnerabilities.
 CMS EA Compliance: Encourages using established tools and libraries to foster
innovation and reduce development time.

SDD Version X.X 8 <Project and release name>

 CMS XLC Design Considerations

3.4 Performance Engineering

Incorporation of Performance Requirements

Given that the SMRT Waste Segregation System is designed for a smaller-scale application, the
performance requirements are tailored accordingly. The key performance requirements include:
1. System Throughput: The system must process a minimum of 100 waste items per hour.
2. Response Time: Real-time control commands must be processed within 200 milliseconds.
3. Scalability: The system must be scaled to handle up to 500 waste items per hour without
significant performance degradation.
4. Availability: The system must have an uptime of 75% to ensure continuous operation.
5. Error Rate: The system should have an error rate of less than 25% in waste item
classification and segregation.

These requirements have been incorporated into the system’s design as follows:

1. System Throughput and Scalability

 Microservices Architecture: Even though the system is small, a microservices

architecture is used to ensure modularity and ease of scaling. Each microservice can
be scaled independently based on load.
 Load Balancing: Simple load balancing strategies are used to distribute tasks evenly
across components, ensuring optimal use of resources.
 Asynchronous Processing: Critical data processing tasks are handled
asynchronously to ensure high throughput and avoid bottlenecks.

2. Availability

 Redundancy and Failover: Basic redundancy mechanisms are implemented for critical
components, such as sensors and database instances, to ensure high availability.
 Continuous Monitoring: Lightweight monitoring tools are used to track system performance
and health, allowing for quick detection and resolution of issues.

3. Error Rate

 Machine Learning Algorithms: Machine learning algorithms are used for accurate
classification of waste items. These algorithms are trained and validated on relevant datasets to
minimize errors.
 Quality Assurance: Rigorous testing and validation processes are in place to ensure the
system's accuracy and reliability.

SDD Version X.X 9 <Project and release name>

CMS XLC System Architecture and Architecture Design

4. System Architecture and Architecture Design

Major Responsibilities of the Software

The SMRT Waste Segregation System has several key responsibilities:

Waste Identification: Accurately classify waste items as recyclable or non-

recyclable using sensors and machine learning algorithms.
Waste Sorting: Physically separate the identified waste items using stepper motor.

System Decomposition and Subsystems

The system is decomposed into the following high-level components/subsystems:

1. Sensor Module

 Responsibility: Detect and capture data on waste items.

 Components: Various sensors (e.g., optical, infrared) connected to
data processing units.
 Role: Serve as the primary input mechanism, providing raw data for
classification.

2. Data Processing and Classification Module

 Responsibility: Process sensor data and classify waste items.

 Components: Machine learning algorithms and data processing
pipelines.
 Role: Transform raw sensor data into actionable classifications
(recyclable or non-recyclable).

3. Control and Sorting Module

 Responsibility: Control stepper motors.

 Components: L293D motor drivers and stepper motors.
 Role: Execute physical sorting actions based on classifications from
the Data Processing and Classification Module.

Interaction and Data Flow Between Subsystems

1. Sensor Module to Data Processing and Classification Module

 Interaction: Sensor data is continuously streamed to the Data

Processing and Classification Module.
 Data Flow: Raw data (e.g., images, material composition) is sent in
real-time for processing.

2. Data Processing and Classification Module to Control and Sorting Module

SDD Version X.X 10 <Project and release name>

CMS XLC System Architecture and Architecture Design

 Interaction: Classified data is transmitted to the Control and Sorting

Module to dictate sorting actions.
 Data Flow: Classification results (e.g., recyclable, non-recyclable)
are sent along with item coordinates and handling instructions.

SDD Version X.X 11 <Project and release name>

CMS XLC System Architecture and Architecture Design

4.1 Logical View

SDD Version X.X 12 <Project and release name>

CMS XLC System Architecture and Architecture Design

4.2 Hardware Architecture

The SMRT Waste Segregation System's hardware architecture is designed to
support its functionality efficiently, ensuring reliable operation and optimal performance.
The processing system is distributed, with components strategically located to optimize
data processing, communication, and control.

Hardware Components

Sensor Devices

 Description: Various sensors such as optical sensors, infrared sensors, and

cameras deployed at waste collection points.
 Location: Distributed across waste collection points.
 Resource Estimates: Minimal processor capacity and memory. Storage
requirements depend on data logging capabilities.

Raspberry Pi Units (Data Processing Units)

 Description: Raspberry Pi boards serving as data processing units for real-time

analysis and classification of waste items.
 Location: Centralized or distributed based on the scale of the system.
 Resource Estimates: Moderate processor capacity and memory to handle real-
time data processing. Auxiliary storage for firmware updates.

Control and Sorting Hardware

 Description: Includes L293D motor drivers and stepper motors for controlling
stepper motors.
 Location: Centralized near the sorting mechanism.
 Resource Estimates: Minimal processor capacity but may require sufficient
memory for storing control algorithms. Auxiliary storage for firmware updates.

SDD Version X.X 13 <Project and release name>

CMS XLC System Architecture and Architecture Design

SDD Version X.X 14 <Project and release name>

CMS XLC System Architecture and Architecture Design

4.2.1 Performance Hardware Architecture

Hardware Components

Raspberry Pi Units (Data Processing Units)

 Description: Raspberry Pi boards serve as data processing units for real-time

analysis and classification of waste items.
 Configuration: Configured with sufficient processor capacity and memory to handle
real-time data processing.
 Reliability Measures: Redundant Raspberry Pi units are deployed for fault
tolerance, minimizing the risk of single points of failure.

Control and Sorting Hardware

 Description: Includes L293D motor drivers and stepper motors for controlling
stepper motors.
 Configuration: Minimal processor capacity but optimized for precise control and
reliable operation.
 Reliability Measures: Redundant control mechanisms are employed to ensure
continuous operation in case of hardware failure.

High Availability Design

 Redundancy: Critical components such as Raspberry Pi units and control mechanisms are
deployed redundantly to minimize single points of failure.
 Fault Tolerance Mechanisms: Automated failover mechanisms are implemented to
ensure seamless transition to backup components in case of failure, reducing system
downtime.
 Continuous Monitoring: While dedicated monitoring servers are not used, built-in
monitoring capabilities within the Raspberry Pi units and control hardware allow for
continuous monitoring of system health and performance.

Single Points of Failure

 Raspberry Pi Units: Redundant Raspberry Pi units mitigate the risk of single points of
failure to some extent. However, failures in power supply or network connectivity can still
impact system performance.
 Control Mechanisms: Hardware failures in control mechanisms such as motor drivers or
stepper motors can potentially disrupt the sorting process, highlighting the importance of
redundancy and fault tolerance measures.

SDD Version X.X 15 <Project and release name>

 CMS XLC System Architecture and Architecture Design

4.3 Software Architecture

The software architecture of the SMRT Waste Segregation System comprises various
components distributed across the hardware infrastructure to support its functionalities efficiently.
Below is a detailed description of the software components, their functions, targeted hardware
components, and their physical location.

Sensor Module Software

Sensor Data Acquisition Software:

 Targeted Hardware: Sensor Devices
 Description: This software component is responsible for capturing data from
sensors such as optical sensors, infrared sensors, and cameras deployed at
waste collection points. It interfaces directly with the sensors to collect data
on waste items, including images and material composition.

Data Processing and Classification Module Software

Machine Learning Algorithms:

 Targeted Hardware: Raspberry Pi Units (Data Processing Units)

 Description: These algorithms are deployed on Raspberry Pi units and are
responsible for analyzing sensor data to classify waste items as recyclable
or non-recyclable based on predefined criteria. The algorithms are optimized
for resource-constrained environments to ensure real-time processing.

Data Processing Pipelines:

 Targeted Hardware: Raspberry Pi Units (Data Processing Units)

 Description: These pipelines process raw sensor data received from the
Sensor Module and apply machine learning algorithms to generate
classifications. They handle the transformation of raw sensor data into
actionable insights, facilitating efficient waste segregation.

Control and Sorting Module Software

Control Algorithms:
 Targeted Hardware: Control and Sorting Hardware
 Description: These algorithms are responsible for controlling the
movements of stepper motors based on classification results from the Data
Processing and Classification Module. They ensure precise and efficient
sorting of waste items according to their classification.

SDD Version X.X 16 <Project and release name>

CMS XLC System Architecture and Architecture Design

System Monitoring Software

 Monitoring Tools:
 Targeted Hardware: N/A (Embedded within hardware components)
 Description: Built-in monitoring capabilities within the hardware components, such
as Raspberry Pi units and control hardware, allow for continuous monitoring of
system health and performance. These tools provide insights into the operational
status of the system and facilitate proactive maintenance and troubleshooting.

SDD Version X.X 17 <Project and release name>

 CMS XLC System Architecture and Architecture Design

4.3.1 Performance Software Architecture

To ensure optimal performance and reliability of the SMRT Waste Segregation System, the
software architecture incorporates several components and configurations. Below are the key
software components and their roles in enhancing performance and reliability:

Machine Learning Algorithms

 Description: These algorithms are responsible for classifying waste items as recyclable or
non-recyclable based on sensor data.
 Performance Enhancement: Optimized machine learning models and algorithms ensure
efficient classification, minimizing processing time and resource utilization.
 Reliability: Rigorous testing and validation of machine learning models enhance the
accuracy and reliability of waste classification.

Control Algorithms

 Description: Control algorithms govern the movements of stepper motors for waste
sorting.
 Performance Enhancement: Optimized control algorithms ensure precise and efficient
sorting operations, reducing sorting time and increasing throughput.
 Reliability: Fault-tolerant algorithms with error handling mechanisms enhance system
reliability by mitigating potential failures during sorting operations.

Data Processing Pipelines

 Description: Data processing pipelines preprocess sensor data and apply machine
learning algorithms for waste classification.
 Performance Enhancement: Streamlined data processing pipelines optimize data flow,
reducing processing latency and improving overall system performance.
 Reliability: Error detection and recovery mechanisms within pipelines ensure data integrity
and system stability, minimizing the impact of processing errors.

High Availability Design

 Redundancy: Critical software components, such as machine learning algorithms and

control algorithms, are deployed redundantly to minimize single points of failure.
 Clustering: In scenarios where clustering is feasible, such as data processing pipelines,
clustering techniques may be employed to achieve high availability and fault tolerance.
 Automated Failover: Automated failover mechanisms are implemented to ensure
seamless transition to backup components in case of failure, reducing system downtime
and enhancing reliability.
 Continuous Monitoring: Real-time monitoring of software components enables proactive
detection of performance issues and potential failures, allowing for timely intervention and
maintenance.

Single Points of Failure

SDD Version X.X 18 <Project and release name>

 CMS XLC System Architecture and Architecture Design

 Machine Learning Models: If machine learning models fail to accurately classify waste
items, it can impact the overall sorting process and system efficiency.
 Control Algorithms: Failures in control algorithms may lead to erratic movements of
stepper motors
 , disrupting sorting operations.
 Data Processing Pipelines: Malfunctioning data processing pipelines can result in delays
or errors in waste classification, affecting system throughput and performance.

4.4 Information Architecture

The SMRT Waste Segregation System stores various types of information to
ensure efficient operation and accurate classification of waste items. Below is a
detailed description of the information stored in the system:

Types of Information Stored

1. Waste Item Data

o Description: Information related to the waste items processed by the
system.
o Details:
 Item ID: Unique identifier for each waste item.
 Material Composition: Description of the material (e.g., plastic,
metal, glass) based on camera analysis.
 Classification: Result of the classification (recyclable or non-
recyclable).
 Image Data: Captured images of the waste item for machine
learning processing using YOLOv3.

2. Camera Data

 Description: Data collected from the cameras used in the system.

 Details:
o Camera ID: Unique identifier for each camera.
o Camera Type: Type of camera (e.g., RGB, infrared).
o Image Captured: Raw images collected by the cameras.
o Timestamp: The time when the image was captured.

The information stored in the SMRT Waste Segregation System includes waste item data
and camera data. This data is critical for the accurate classification and sorting of waste
items using camera-based input and machine learning models (YOLOv3). The system
ensures that no personally identifiable information (PII), individually identifiable information
(IIF), or personal health information (PHI) is stored, thereby maintaining data privacy and
security.

SDD Version X.X 19 <Project and release name>

 CMS XLC System Architecture and Architecture Design

4.4.1 Records Management

Federal regulations issued by the National Archives and Records Administration
(NARA) are outlined in 36 Code of Federal Regulations (CFR) - Subchapter B -
Records Management. Business owners must contact the Office of Strategic
Operations and Regulatory Affairs (OSORA) to initiate the record management
process.

4.4.1.1 Data
The SMRT Waste Segregation System relies on various types of data inputs to function
effectively. Below is a detailed list of all data supplied to the system, including the format
of the data and the sources (who/what is supplying the data).

Data Inputs

1. Waste Item Data

o Format: Electronic Data
o Supplied By: Camera System
o Details: Captured images of waste items are supplied by the camera
system. This data is then used by the machine learning model (YOLOv3) for
classification purposes.
2. Camera Data
o Format: Electronic Data
o Supplied By: Camera System
o Details: This includes raw image data captured by the cameras. Each
camera provides a continuous image data feed which is used to identify and
classify waste items.

Description of Data Sources

1. Camera System
o Role: The primary data source for the system. It captures images of the
waste items passing through the system and supplies these images to the
machine learning model for analysis and classification.
o Components:
SDD Version X.X 20 <Project and release name>
 CMS XLC System Architecture and Architecture Design

 Cameras: High-resolution cameras mounted in strategic locations to

capture images of waste items.
 Data Transmission: Network connections that transmit the captured
images to the processing unit (Raspberry Pi).

The SMRT Waste Segregation System primarily relies on electronic data supplied by the
camera system. This data is crucial for the identification and classification of waste items
using the YOLOv3 machine learning model. The camera system captures high-resolution
images of the waste items, which are then processed to determine their material
composition and classification as recyclable or non-recyclable. No paper or manual input
data is used in this system, ensuring a fully automated and efficient waste segregation
process.

4.4.1.2 Manual/Electronic Inputs

After manual or electronic inputs are entered into the master file/database and verified,
they undergo a series of processing steps. Here's a detailed description of what
happens to these inputs:

1. Data Capture

 Inputs: Images of waste items.

 Format: Electronic (captured by cameras).
 Action: Captured images are sent to the processing unit for verification.

2. Verification

 Action: The captured images are verified for clarity and relevance.
 Outcome: Verified images are saved in the master file/database.

3. Data Processing

 Action: Verified images are processed using the YOLOv3 machine learning
model.
 Outcome: Waste items are classified as recyclable or non-recyclable.

4. Action Execution

 Action: Based on the classification, control signals are sent to the sorting
mechanisms.
 Outcome: Waste items are physically sorted.

5. Data Storage and Logging

 Action: Classification results and sorting actions are logged.

 Outcome: Data is stored for future reference and analysis.

SDD Version X.X 21 <Project and release name>

 CMS XLC System Architecture and Architecture Design

This process ensures that manual or electronic inputs are accurately verified, processed, and
acted upon within the SMRT Waste Segregation System. The data flow diagram provides a visual
representation of the steps involved, from data capture to storage and logging, ensuring a clear
understanding of the entire process.

4.4.1.3 Master Files

Image Data: Captures images of waste items for classification.
Classification Data: Indicates whether waste is recyclable or non-recyclable.
Sorting Action Data: Provides commands for motors to physically sort waste.
System Logs: Records system activities and errors for monitoring and troubleshooting.
Configuration Data: Sets system parameters and behavior. Performance Data: Monitors and
reports on system performance.

4.5 Internal Communications Architecture

Not Applicable

SDD Version X.X 22 <Project and release name>

CMS XLC System Architecture and Architecture Design

4.6 System Architecture Diagram

SDD Version X.X 23 <Project and release name>

CMS XLC System Design

5. System Design
5.1 Business Requirement
 Efficient Waste Segregation: Accurately classify waste items into recyclable and non-
recyclable categories.
 Real-time Monitoring: Provide continuous monitoring of waste segregation operations
and system performance.
 Data Security: Implement robust security measures to protect sensitive data and ensure
compliance with privacy regulations.
 Scalability: Design the system to accommodate future expansion and integration of
additional functionalities.
 Reliability and Availability: Ensure reliable and uninterrupted system operation for
continuous waste segregation.
 Integration Capability: Enable seamless integration with existing waste management
infrastructure.
 Compliance: Ensure adherence to regulatory standards and industry best practices in
waste management.

5.2 Database Design

The database design for the SMRT Waste Segregation System encompasses various tables to
store data related to waste items, classifications, system logs, configuration settings, and
performance metrics. Here's a summary of the database schema:

SDD Version X.X 24 <Project and release name>

 CMS XLC System Design

5.2.1 Data Objects and Resultant Data Structures

1. Waste Item Data Object

o Data Structure:
 Image: Binary
 Classification: String (e.g., "Recyclable", "Non-recyclable")
 Timestamp: DateTime
o Description: Represents a waste item captured by the system, including its image,
classification, and timestamp.

2. System Log Data Object

o Data Structure:
 Log ID: Integer
 Timestamp: DateTime
 Message: Text
o Description: Stores information about system activities and errors, including a
unique identifier, timestamp, and textual description.

3. Trash Bin Status Data Object

o Data Structure:
 Bin ID: Integer
 Status: String (e.g., "Empty", "Partially Full", "Full")
 Timestamp: DateTime
o Description: Represents the status of a trash bin, including its unique identifier,
current status, and timestamp of status update.

Functions

1. CaptureWasteItem Function
o Input: Image (Binary), Timestamp (DateTime)
o Output: None
o Description: Captures a waste item image along with the timestamp and initiates
the classification process.

2. LogSystemActivity Function
o Input: Timestamp (DateTime), Message (Text)
o Output: None
o Description: Records system activities and errors with the corresponding
timestamp and message.

These functional data objects and functions align with the system scope, focusing on waste
classification, monitoring trash bin status, and ensuring reliable system operation despite potential
connectivity issues.

5.2.2 File and Database Structures

1. Relational Database:
o Tables:
 Waste Items: Stores waste item data including images, classifications,
and timestamps.
SDD Version X.X 25 <Project and release name>
CMS XLC System Design

System Logs: Records system activities and errors with timestamps

and messages.
 Trash Bin Status: Manages status information of trash bins.
o Attributes:
 Waste Items: ID, Image (Binary), Classification, Timestamp
 System Logs: Log ID, Timestamp, Message
 Trash Bin Status: Bin ID, Status, Timestamp
o Database Management System (DBMS): MySQL
2. File Storage for Images:
o Binary image data captured by the system will be stored in a separate file
storage system or cloud storage service.
o References or URLs to these images will be stored in the Waste Items table.

Location and Distribution:

 The relational database will be hosted on dedicated database servers within the
system's network infrastructure.
 Data distribution:
o Waste item data, system logs, and trash bin status information will be stored
in the same database server.
o For scalability and fault tolerance, data may be replicated across multiple
database servers using techniques like master-slave replication.
 Image files will be stored in a centralized file storage system accessible via secure
APIs or URLs.
 Access to the database and file storage will be managed through appropriate
network configurations and security measures.

Changes from Logical Data Model (LDM):

 The physical data model may introduce optimizations such as indexing, partitioning,
or denormalization to improve performance and scalability.
 The choice of MySQL as the DBMS may influence certain database design
decisions and structures compared to the abstract LDM.

SDD Version X.X 26 <Project and release name>

CMS XLC System Design

5.2.2.1 Database Management System Files

The detailed design of the DBMS files is typically documented in a separate Database
Design Document (DDD). Below is an overview of the structure and content that would
be included in the DDD for the system's DBMS files:

1. Storage Configuration:

 Allocation of storage space for each table.

 Configuration of tablespaces, data files, and log files.

2. Backup and Recovery Strategy:

 Scheduled backups of database files and transaction logs.

 Procedures for database recovery in case of data loss or corruption.

3. Security Measures:

 User access control with role-based permissions.

 Encryption of sensitive data at rest and in transit.

4. Performance Tuning:

 Configuration of memory allocation, buffer pool size, and cache settings.

 Query optimization techniques such as index tuning and query rewriting.

5. Maintenance Procedures:

 Regular database maintenance tasks such as index rebuilds and statistics updates.
 Procedures for monitoring database health and performance.

6. Database Documentation:

 Description of each table, including column definitions and data types.

 Relationships between tables, documented using entity-relationship diagrams or similar
visual representations.

SDD Version X.X 27 <Project and release name>

 CMS XLC System Design

5.2.2.2 Non-Database Management System Files

Below is a detailed description of all non-DBMS files used in the system, along with their usage,
module interactions, and file structures:

 WasteImages:
o Usage: Input (images of waste items).
o Module Interactions: Accessed and processed by the Image Processing Module.
o File Structure: Binary image files without explicit record structures.
 SystemLogs:
o Usage: Output (system log entries).
o Module Interactions: Written by the System Logging Module.
o File Structure: Text files containing log entries with timestamps and messages.
 TrashBinStatus:
o Usage: Input (updates to trash bin status) and Output (status information).
o Module Interactions: Updated by the Control Module, read by the Monitoring
Module.
o File Structure: Text files with records representing each trash bin's status, including
bin ID, status, and timestamp.

Additional Information:

 Access Method: Sequential access for reading and writing.

 Record Length: Variable length based on the content.
 File Size: Varies based on the number of images, log entries, and trash bins.
 Update Frequency: TrashBinStatus file updated whenever a status change occurs,
SystemLogs file continuously appended with new log entries.
 Backup and Recovery: Regular backups scheduled for all files, with procedures for
recovery in case of data loss or corruption.

SDD Version X.X 28 <Project and release name>

 CMS XLC System Design

5.3 Data Conversion

The data conversion process involves transforming data from one format to another to ensure
compatibility and consistency within the system. Below are the key aspects of the data conversion
process:

1. Source Data Formats:

o Raw data may be received in various formats such as CSV, JSON, or proprietary
formats from external sources or sensors.
2. Conversion Requirements:
o Data must be converted into a standardized format compatible with the system's
data model and processing requirements.
3. Data Cleansing and Validation:
o Before conversion, data undergoes cleansing and validation to identify and correct
any inconsistencies, errors, or missing values.
4. Transformation Rules:
o Transformation rules are applied to map data fields from the source format to the
target format, ensuring accurate representation and interpretation of data.
5. Data Enrichment:
o Additional data enrichment processes may be applied during conversion, such as
geocoding, normalization, or aggregation, to enhance the quality and usefulness of
the data.
6. Conversion Tools and Scripts:
o Conversion is facilitated by using specialized tools, scripts, or custom software
developed to automate the process and handle large volumes of data efficiently.
7. Testing and Validation:
o Converted data undergoes rigorous testing and validation against predefined criteria
to ensure accuracy, completeness, and adherence to business rules.
8. Documentation:
o Detailed documentation of conversion procedures, rules, and mappings is
maintained for reference and audit purposes.
9. Data Migration Strategy:
o Data conversion is integrated into the overall data migration strategy, which includes
planning, execution, monitoring, and post-migration validation activities.
10. Monitoring and Maintenance:
o Ongoing monitoring and maintenance of converted data are essential to address
any issues, ensure data integrity, and support system updates or enhancements.

5.4 User Machine-Readable Interface

 Operational Users:

 Description: Operational users are individuals responsible for directly interacting with
the waste segregation system in their daily operations. They oversee the functioning of
the system, monitor waste segregation processes, and ensure smooth operation.

 Data Entry Personnel:

SDD Version X.X 29 <Project and release name>

 CMS XLC System Design

 Description: Data entry personnel are tasked with inputting and verifying data into the
system. They update trash bin statuses, record waste classification results, and ensure
the accuracy and completeness of data entered into the system.

 System Operators:

 Description: System operators are responsible for monitoring and managing the waste
segregation system. They oversee system performance, troubleshoot any issues that
arise, and make necessary configurations to ensure optimal operation.

 System Maintainers:

 Description: System maintainers are tasked with maintaining the overall health and
functionality of the waste segregation system. They apply system updates, resolve
technical issues, and perform routine maintenance tasks to ensure the system operates
smoothly.

 Trainers:

 Description: Trainers provide training and support to operational users and data entry
personnel. They educate users on how to effectively use the waste segregation system,
impart best practices, and provide guidance on troubleshooting procedures when
needed.

5.4.1 Inputs
The waste segregation system incorporates various input media for users/operators to provide
information. These input methods are mapped to high-level data flows and include the following:

1. Web-Based Interface:
o Description: Users interact with the system through a web-based interface
accessible via browsers on desktop and mobile devices.
o Data Flow: User inputs are transmitted over the internet to the system's servers for
processing.
o Data Elements: Data elements include waste bin statuses, classification results,
system configuration settings, etc.
o Edit Criteria: Mandatory fields are marked, ensuring completeness of required
information. Validation rules enforce data integrity.
o Access Restrictions: User authentication mechanisms enforce access control,
limiting system access to authorized personnel only.
o Security Considerations: Encryption protocols (e.g., HTTPS) secure data
transmission to prevent unauthorized access.
o Miscellaneous Messages: Users receive feedback messages confirming
successful data submission or alerting them to any errors encountered

SDD Version X.X 30 <Project and release name>

CMS XLC System Design

5.4.2 Outputs

Data Display Screens and GUIs:

 Identification: GUIs and data display screens will be identified by their functionality and
purpose, aligning with our discussions on user interactions and system requirements.
 Contents: These interfaces will present real-time data on waste bin statuses and system
alerts in a user-friendly format. Data elements will be clearly labeled and organized to
facilitate easy comprehension and navigation.
 Purpose: GUIs serve as the primary interface for users to interact with the system,
allowing them to monitor waste segregation processes, view classification results, and
manage system operations.

5.5 User Interface Design

Not Applicable

5.5.1 Section 508 Compliance

Not Applicable

SDD Version X.X 31 <Project and release name>

 CMS XLC Operational Scenarios

6. Operational Scenarios
The system functions as an automated waste segregation system, focusing on the classification
and segregation of recyclable and non-recyclable waste. Users interact with the system through
various interfaces to monitor, manage, and optimize waste segregation processes. Key
functionalities include:

1. Waste Identification: Accurately classify waste items as recyclable or non-recyclable using

machine learning algorithms trained on a diverse dataset of waste images.
2. Waste Segregation: Physically separate identified waste items using stepper motors.
3. System Monitoring: Provide real-time monitoring of waste segregation processes and
system performance through web-based interfaces.
4. Alerts and Notifications: Generate alerts and notifications to inform users when the trash
bin is nearly full or when there are system errors or anomalies.

Operational Scenarios

Scenario 1: Waste Segregation Process

1. User places waste items into the waste bin equipped with camera.
2. The system captures images of the waste items and sends them to the data processing
module.
3. Machine learning algorithms analyze the images to classify waste items as recyclable or
non-recyclable.
4. Based on the classification results, the control module activates stepper motors to sort the
waste items into separate bins.
5. The segregated waste items are collected for further processing or disposal.

Scenario 2: Alert Notification

1. The system detects that the trash bin is nearing its capacity limit, reaching 75% full.
2. An alert is triggered, and a notification is sent to the designated user or maintenance
personnel.
3. The notification includes details about the fill level and instructions for emptying the bin to
prevent overflow.

These scenarios illustrate how the system operates and interacts with users and external
interfaces to facilitate efficient waste segregation processes and ensure optimal system
performance.

SDD Version X.X 32 <Project and release name>

 CMS XLC Detailed Design

7. Detailed Design
To facilitate the actual build and integration of the system, the following steps and procedures are
outlined:

Hardware Component Integration:

1. Component Procurement: Source and acquire all necessary hardware components,

including Raspberry Pi units, sensors, cameras, motor drivers, and stepper motors.
2. Assembly Instructions: Provide detailed assembly instructions or diagrams for integrating
hardware components into the waste segregation system framework.
3. Testing Procedures: Develop testing procedures to verify the functionality and
compatibility of integrated hardware components, ensuring proper communication and
interaction between sensors, actuators, and control modules.
4. Installation Guidelines: Provide guidelines for installing the assembled hardware
components into the designated environment, ensuring proper positioning and alignment
for optimal performance.

Software Component Integration:

1. Software Development: Develop software modules for data processing, machine learning
algorithms, control logic, and system monitoring functionalities.
2. Code Integration: Integrate individual software modules into a cohesive software package,
ensuring compatibility and seamless interaction between different components.
3. API Documentation: Document APIs and interfaces for inter-module communication,
providing clear guidelines for data exchange and function calls.
4. Testing and Debugging: Conduct rigorous testing and debugging procedures to identify
and resolve software integration issues, ensuring reliability and stability of the system.

Hardware-Software Integration:

1. Interfacing Protocols: Define communication protocols and interfaces between hardware

and software components, ensuring smooth data exchange and command execution.
2. Integration Testing: Perform integration testing to validate the interaction between
hardware and software components, simulating real-world scenarios and user interactions.
3. Feedback Mechanisms: Implement feedback mechanisms to ensure that software
commands are executed correctly by hardware components, with error handling and
recovery procedures in place.
4. Optimization Strategies: Optimize system performance through fine-tuning of hardware-
software interactions, minimizing latency and maximizing throughput for efficient waste
segregation operations.

COTS Package Integration:

1. Package Selection: Identify and evaluate commercial off-the-shelf (COTS) packages

suitable for specific system requirements, such as web-based interfaces, machine learning
frameworks, or database management systems.
2. Integration Compatibility: Assess the compatibility of selected COTS packages with
existing hardware and software components, ensuring seamless integration and
interoperability.

SDD Version X.X 33 <Project and release name>

CMS XLC Detailed Design

3. Customization and Configuration: Customize and configure COTS packages to align

with system specifications and functional requirements, adapting them to suit the unique
needs of the waste segregation system.
4. Testing and Validation: Conduct thorough testing and validation of integrated COTS
packages within the overall system framework, verifying their performance, reliability, and
compliance with system standards and specifications.

7.1 Hardware Detailed Design

 Raspberry Pi Units:

 Model: Raspberry Pi 4B
 Processor: Broadcom BCM2711, Quad-core Cortex-A72 (ARM v8) 64-bit SoC @
1.5GHz
 Memory: 2GB/4GB/8GB LPDDR4-3200 SDRAM
 Storage: MicroSD card slot for operating system and data storage
 Power Input: 5V via USB-C connector
 Connectivity: Dual-band 802.11ac wireless LAN, Bluetooth 5.0, Gigabit Ethernet

 Sensors:

 Type: Optical sensors, infrared sensors

 Power Input: Varies based on sensor requirements
 Interface: Digital (I2C, SPI) or Analog

 Cameras:

 Type: High-resolution cameras supporting video capture

 Resolution: 1080p or higher for accurate waste identification
 Interface: CSI (Camera Serial Interface) connector for direct connection to Raspberry Pi

 Motor Drivers:

 Type: L293D motor drivers for controlling stepper motors

 Voltage Rating: Compatible with Raspberry Pi GPIO voltage levels

 Stepper Motors:

 Type: Bipolar or unipolar stepper motors depending on application requirements

 Interface: Direct connection to motor drivers for control signals

 Power Supply:

 Output Voltage: 5V for Raspberry Pi units and low-voltage components

 Current Rating: Sufficient to power all components simultaneously
 Input Voltage: Compatible with standard AC power outlets (110-240V)
 Safety Features: Overcurrent protection, short circuit protection

SDD Version X.X 34 <Project and release name>

CMS XLC Detailed Design

7.2 Software Detailed Design

Service Identifier: WasteSegregationService

 Classification: Application service

 Definition: This service is responsible for coordinating the waste segregation process,
including waste identification, classification, and segregation based on predefined rules and
criteria.
 Requirements:
o Functional: Identify and classify waste items, control motor movements for
segregation, monitor waste bin levels.
o Non-functional: Real-time processing, high accuracy in waste classification, fault
tolerance.

Internal Data Structures:

 WasteItem: Structure to hold information about a waste item, including image data,
classification results, and metadata.
 WasteBin: Structure representing a waste bin, including capacity, current level, and
location.

Constraints:

 Real-time processing: The service must respond within predefined time limits to ensure
smooth operation.
 Storage limitations: The service should optimize storage usage to minimize memory
footprint.
 Accuracy requirements: Classification accuracy must meet predefined thresholds to ensure
proper waste segregation.

Composition:

 This service relies on machine learning models for waste classification and motor control
modules for waste segregation.

Users/Interactions:

 Interacts with CameraService for capturing waste images.

 Collaborates with MotorControlService for controlling stepper motors.
 Communicates with SensorService for monitoring waste bin levels.

Processing:

 Implements image processing algorithms for waste classification.

 Utilizes control algorithms to determine motor movements for waste segregation.
 Implements error handling mechanisms for fault tolerance.

Interfaces/Exports:

 classifyWasteItem(imageData: Image): Function to classify waste items based on

captured images.
SDD Version X.X 35 <Project and release name>
CMS XLC Detailed Design

 controlMotorMovement(movementData: Movement): Function to control stepper motors

for waste segregation.
 monitorWasteBinLevel(binID: int): Function to monitor waste bin levels and trigger alerts
if nearly full.

7.3 Security Detailed Design

Not Applicable
7.4 Performance Detailed Design
 Capacity and Volume Requirements/Estimates:

 Determine the amount of data generated by the system over a given period.
 Estimate the storage capacity needed to store this data for a specified duration,
considering growth projections.

 Performance Expectations:

 Define the performance metrics related to backup, recovery, and archiving processes,
such as backup speed, recovery time objective (RTO), and recovery point objective
(RPO).

 Availability Requirements:

 Establish availability requirements for backup and recovery operations, including uptime
and accessibility of backup data.

 Performance Design to Meet Capacity Requirements:

 Implement a scalable backup solution capable of handling the anticipated data volume
growth.
 Use efficient compression and deduplication techniques to optimize storage utilization.

 Reliability Design to Meet Availability Requirements:

 Ensure redundancy in backup storage infrastructure to mitigate the risk of data loss due
to hardware failures.
 Implement disaster recovery mechanisms to replicate backup data across
geographically dispersed locations.

 Backup, Recovery, and Archive Design:

 Use a combination of full backups, incremental backups, and differential backups to

optimize storage and backup time.
 Implement a backup schedule that aligns with business requirements, considering
factors such as data criticality and frequency of data updates.
 Employ encryption mechanisms to secure backup data both in transit and at rest.
 Regularly test backup and recovery procedures to validate their effectiveness and
identify any potential issues proactively.
 Implement versioning and retention policies to manage archived data effectively,
ensuring compliance with regulatory requirements and minimizing storage costs.
SDD Version X.X 36 <Project and release name>
CMS XLC Detailed Design

7.5 Internal Communications Detailed Design

 Not Applicable

SDD Version X.X 37 <Project and release name>

 CMS XLC System Integrity Controls

8. System Integrity Controls

System Integrity Control refers to a set of measures, mechanisms, and procedures

implemented to ensure that a system operates correctly, securely, and reliably. These
controls are designed to protect data and system resources from unauthorized access,
corruption, or tampering, and to ensure the accuracy and consistency of data over its
lifecycle. They are essential for maintaining trust in the system's operations and for
compliance with regulatory and organizational standards.

Importance of System Integrity Control

1. Security: Protects against unauthorized access and tampering.

2. Accuracy: Ensures data accuracy and consistency.
3. Reliability: Maintains the reliable operation of the system.
4. Compliance: Helps meet regulatory and legal requirements.
5. Auditability: Provides a clear audit trail for investigating incidents and verifying system
operations.
6. Trust: Builds trust among users and stakeholders in the system’s operations and data.

SDD Version X.X 38 <Project and release name>

 CMS XLC External Interfaces

9. External Interfaces
Not Applicable

9.1 Interface Architecture

Not Applicable
9.2 Interface Detailed Design
Not Applicable

SDD Version X.X 39 <Project and release name>

CMS XLC Appendix A: Record of Changes

Appendix A: Record of Changes

Instructions: Provide information on how the development and distribution of the SDD
will be controlled and tracked. Use the table below to provide the version number, the
date of the version, the author/owner of the version, and a brief description of the
reason for creating the revised version.
Table 1 - Record of Changes
Version Number Date Author/Owner Description of Change
<X.X> <MM/DD/YYYY> CMS <Description of Change>
<X.X> <MM/DD/YYYY> CMS <Description of Change>
<X.X> <MM/DD/YYYY> CMS <Description of Change>

SDD Version X.X 40 <Project and release name>

CMS XLC Appendix B: Acronyms

Appendix B: Acronyms
Instructions: Provide a list of acronyms and associated literal translations used within
the document. List the acronyms in alphabetical order using a tabular format as
depicted below.
Table 2 - Acronyms
Acronym Literal Translation
<Acronym> <Literal Translation>
<Acronym> <Literal Translation>
<Acronym> <Literal Translation>

SDD Version X.X 41 <Project and release name>

CMS XLC Appendix C: Glossary

Appendix C: Glossary
Instructions: Provide clear and concise definitions for terms used in this document that
may be unfamiliar to readers of the document. Terms are to be listed in alphabetical
order.
Table 3 - Glossary
Term Acronym Definition
<Term> <Acronym> <Definition>
<Term> <Acronym> <Definition>
<Term> <Acronym> <Definition>

SDD Version X.X 42 <Project and release name>

CMS XLC Appendix D: Referenced Documents

Appendix D: Referenced Documents

Table 4 - Referenced Documents
Document Name Document Location and/or URL Issuance Date

SDD Version X.X 43 <Project and release name>

CMS XLC Appendix E: Approvals

Appendix E: Approvals
The undersigned acknowledge that they have reviewed the SDD and agree with the information
presented within this document. Changes to this SDD will be coordinated with, and approved by, the
undersigned, or their designated representatives.
Instructions: List the individuals whose signatures are desired. Examples of such
individuals are Business Owner, Project Manager (if identified), and any appropriate
stakeholders. Add additional lines for signature as necessary.
Table 5 - Approvals
Document Approved By Date Approved

Name: <Name>, <Job Title> - <Company> Date

Name: <Name>, <Job Title> - <Company> Date

Name: <Name>, <Job Title> - <Company> Date

Name: <Name>, <Job Title> - <Company> Date

SDD Version X.X 44 <Project and release name>

CMS XLC Appendix F: Additional Appendices

Appendix F: Additional Appendices

Instructions: Utilize additional appendices to facilitate ease of use and maintenance of
the document. Suggested appendices include (but are not limited to):
 Software Architecture Diagrams - provide the functional hierarchy diagrams,
structured organization diagrams, or object-oriented diagrams that show the
various segmentation levels of the software architecture down to the lowest
level.
 Data Dictionary - provide definitions of all processes, data flows, data
elements, and data stores.
 Requirements Traceability Matrix - demonstrate backward traceability of the
system and software architectural designs to the functional and
nonfunctional requirements documented in the Requirements Document.
 CMS Section 508 Product Assessment - demonstrate compliance or non-
compliance with accessibility standards provided in Section 508 of the
Rehabilitation Act of 1973, as amended effective June 20, 2001 The template
for this appendix is available at https://www.cms.gov/Research-Statistics-Data-
and- Systems/CMS-Information-
Technology/XLC/Downloads/Sect508ProdAssessment.docx.

SDD Version X.X 45 <Project and release name>

CMS XLC Appendix G: Notes to the Author/Template Instructions

Appendix G: Notes to the Author/Template Instructions

This document is a template for creating an SDD for a given investment or project. The
final document should be delivered in an electronically searchable format. The SDD
should stand on its own with all elements explained and acronyms spelled out for
reader/reviewers, including reviewers outside CMS who may not be familiar with CMS
projects and investments.
This template includes instructions, boilerplate text, and fields. The developer should
note that:
 Each section provides instructions or describes the intent, assumptions,
and context for content included in that section. Instructional text appears in
blue italicized font throughout this template.
 Instructional text in each section should be replaced with information specific
to the particular investment.
 Some text and tables are provided as boilerplate examples of wording
and formats that may be used or modified as appropriate.
When using this template, follow these steps:
1. Table captions and descriptions are to be placed left-aligned, above the table.

2. Modify any boilerplate text, as appropriate, to your specific investment.

3. Do not delete any headings. If the heading is not applicable to the

investment, enter “Not Applicable” under the heading.

4. All documents must be compliant with Section 508 requirements.

5. Figure captions and descriptions are to be placed left-aligned, below the

figure. All figures must have an associated tag providing appropriate
alternative text for Section 508 compliance.

6. Delete this “Notes to the Author/Template Instructions” page and all

instructions to the author before finalizing the initial draft of the
document.

SDD Version X.X 46 <Project and release name>