Internet-of-Things Alliance (IOTA) Charter
The parties to this Charter affirm their desire to prepare students at Oregon State University for careers in practicing engineering of Internet-of-Things (IoT) systems. Such technologies, exemplified by building-monitoring systems as well as networks of devices and/or bots, have grown in economic and cultural importance. Therefore, the parties to this Charter commit to form a community wherein students develop relevant practice-oriented skills, identify personally meaningful problems, take initiative, design technical solutions, obtain support, implement solutions, give and receive mentorship, interact with industry and university experts, serve as leaders in professionalism and innovation, and showcase IoT systems.
- 1 - General Provisions
- 2 - Member Commitments
- 2.1 - School of Electrical Engineering and Computer Science (EECS)
- 2.2 - The CS Online Capstone
- 2.3 - On-campus Capstones
- 2.4 - The Master's in Software Innovation (MSSWI) Track
- 2.5 - The CS Network Security Course
- 2.6 - The CS Undergraduate Operating Systems Courses
- 2.7 - The OSU Robotics Club
- 2.8 - The Hackathon Club
- 2.9 - The Security Club
- 2.10 - Inventors Enterprise
Section 1: General Provisions
Section 1.1: Alliance Membership
IOTA is a type of a community of practice: It is a community of members from different backgrounds who help one another to master a shared area of technical practice, specifically engineering of IoT systems. These members are the following:
- The School of Electrical Engineering and Computer Science (EECS)
- The Computer Science (CS) Online Capstone
- The CS On-campus Capstone
- The CS On-campus Capstone
- The Master's in Software Innovation (MSSWI) Track
- The CS Network Security Course
- The CS Undergraduate Operating Systems Courses
- The OSU Robotics Club
- The Hackathon Club
- The Security Club
- Inventors Enterprise Club
Each member is responsible on a per-academic year basis for identifying one individual to represent that member's interests in discussions concerning the Alliance. The member will arrange for that individual's name and contact information to appear in Section 2 of this Charter.
Additional parties may become members of this Alliance with the unanimous consent of existing members. A member may be removed from the Alliance by unanimous consent of the other members. An existing member may initiate a motion to admit a new member, or to remove an existing member, by sending an email to all representatives of existing members. If no member publicly objects via email to the admission or removal within one month of this email, then the membership list in Section 1 of this Charter will be changed as proposed.
EECS will publish and maintain an up-to-date copy of this IOTA Charter in a prominent location online, reflecting modifications that may occur.
The current members affirm their intention to maintain a welcoming culture of participation. Therefore, they express a desire generally to admit any new members who offer significant new contributions aligned with the interests of the Alliance. Likewise, members affirm an intention not to expel one another from the Alliance, except in cases where a member routinely fails to keep commitments to the Alliance.
Section 1.2: Charter Modifications
The members of this Alliance may, by unanimous consent, modify Section 1 of this Charter. A member may move to initiate changes to Section 1 by sending an email to all representatives and, if no objections are raised publicly within 1 month of this email, the Charter will be changed as proposed.
In addition, each member may unilaterally modify the respective subsection of Section 2 or withdraw from membership by sending an email to all representatives of members, and the Charter will immediately be changed as proposed.
The members of this Alliance affirm their intent that any modifications to this Charter will be consistent with the spirit of the Mission Statement above. Members affirm their intention to provide one another with timely warning of future changes that could negatively impact one another, in order that members can accommodate changes in others’ commitments.
Section 1.3: Alliance Objectives
Each member of this Alliance commits to the following core objectives, to the extent that doing so is feasible and beneficial for the member:
- To conduct events, such as non-credit seminars, that are of mutual interest to other members of the Alliance
- To share resources such as documents, training materials, data, software components, tools and other hardware
- To contribute new resources of potential value to the Alliance and its members
- To help IOTA as a whole, as well as individual students, to earn a reputation for engineering of IoT systems
- To promote an inclusive, diverse community that respects the distinct interests of other members and their students
Each member recognizes that other members pursue these core objectives in varied ways, due to differences in the members' priorities, interests and constraints. The members further recognize that each other member's interests extend beyond engineering of IoT systems, so other members may at times need to make choices that are not perfectly aligned with the interests of the Alliance. Nonetheless, the members of IOTA commit to invest time and effort to collaboratively support student success as much as possible in the area of practicing engineering of IoT systems.
Section 2: Member Commitments
Each member will document its commitments to the Alliance in a subsection below, along with the name and contact information of the member's representative to the Alliance.
Section 2.1: School of Electrical Engineering and Computer Science (EECS)
Tom Weller (email@example.com) represents EECS.
EECS will fund one 0.49 GTA who will serve as the "IOTA Community Coordinator,” who will be responsible for the following activities:
- Creating an IOTA website, or a section within the EECS website, that will contain several sections:
- An up to date copy of this IOTA charter
- An online calendar reflecting all member events relevant to the Alliance
- A repository of digital resources shareable by all Alliance members (e.g., training materials, datasets, and reusable software components)
- A catalog of non-digital resources that members have indicated they are open to sharing with other Alliance members (e.g., tools and hardware)
- An online portfolio system that promotes the Alliance's reputation by showcasing what its members and their students are accomplishing
- A record of which students have led seminars and other member events in the past, to facilitate hiring of those students (e.g., post-graduation or as GAs)
- Coordinating with members to help them obtain resources needed for member events
- Coordinating with other EECS staff to showcase student projects originating in the IoT Alliance at industry-oriented events that EECS generally holds to promote the reputation of students and the school
- Helping members to accumulate and improve resources (e.g., updating training materials after seminars)
- Creating and managing one or more mailing list to facilitate communications among member representatives and/or students associated with members
- Maintaining a database of student participation in events (e.g., seminars) by consolidating data
provided by members after events occur
- This data will indicate several consolidated metrics for each student.
- The Community Coordinator will work with the Alliance's member representatives (particularly Capstone leaders) to precisely define appropriate metrics to track.
- The Community Coordinator will provide these consolidated data to Alliance members in a manner that respects both student privacy and members' instructional interests
- Ensuring that all collection and sharing of information related to student activities is done in a manner compliant with university policies
The Community Coordinator will interact regularly with all members of the Alliance and will ultimately report to the representative of the MSSWI Track.
Due to the fact that effectively satisfying the job description above will require skills in both web development and in engineering of IoT systems, it is possible that no single TA at OSU has all the necessary abilities. Therefore, instead of providing a single 0.49 GTA with all of these skills, it is possible that EECS will instead sometimes provide two 0.25 GTAs who have complementary skills and can divide the responsibilities.
In addition to the GTA support, above, EECS will allow Alliance members to reserve conference rooms in Kelley Engineering Center for conducting IOTA events on weekends and after 5pm on weekdays. Specifically, IOTA member representatives (faculty) may request access to the Kelley conference room scheduling system, and these representatives may then reserve space on evenings and weekends. IOTA members may be asked by EECS to restrict their use of space only to certain rooms. It is understood that IOTA does not enjoy any particular priority over other groups for use of this conference room space, and therefore rooms may not be available during certain times and dates.
Section 2.2: The CS Online Capstone
Ben Brewster (firstname.lastname@example.org) represents the CS Online Capstone (i.e., Ecampus Post-Baccalaureate Capstone). This Capstone will include at least one assignment and/or extra credit for participating in events conducted by members of the Alliance, which events are available to students in the Post-Baccalaureate program and are made available to the class as a whole, in proportion to metrics to be tracked by the Community Coordinator (Section 2.1). These metrics will take into account the extent to which Capstone students (i.e., seniors) participate in events in ways that promote skills development by less experienced students (such as freshmen and sophomores). The details of these metrics are as-yet to be determined.
Section 2.3: On-campus Capstones
Each On-campus Capstone will organize student teams into domains that reflect the nature of each team's project. Each student Capstone team will be in one of these domains. One or more of these domains in CS, and one or more of these domains in ECE, will be related to IoT (though its name might be something different). The domains in CS Capstone will likely differ from the domains in ECE Capstone. The point is that student teams will be grouped so that all the teams within each Capstone now have a domain.
Each Capstone will then assign each domain to a TA, recognizing that some TAs might be assigned to multiple domains if some domains have relatively few teams. Each Capstone TA will have the option to organize events that students within that domain may attend so that teams can learn from one another and/or collaborate on components of mutual interest; however, this activity will not be required as part of the TAs expected duties for FTEs. For example, one of the domains in CS Capstone might be related to embedded devices, and students in that domain's teams might decide host an event to create certain components that all of them can then reuse in their respective Capstone projects.
The CS and ECE Capstone TAs who oversee domains related to IoT have the option of notifying each other of events that they coordinate, so that these TAs can advertise one another's events, if they so choose. In addition, they might notify the IOTA Community Coordinator of these events, so that other members of IOTA may attend the events. Furthermore, to the extent possible, the Community Coordinator can collect resources on event topics that could be placed in the IOTA online repository (Section 2.1).
Finally, both On-Campus Capstone representatives affirm the desirability of letting appropriately-qualified ECE seniors register for CS Capstone instead of ECE Capstone, and vice versa, and they express a commitment to work toward necessary policy and procedural changes needed to make that possible.
Section 2.3.1: Specific ECE Capstone Commitments
Don Heer (email@example.com) represents the ECE Capstone.
In addition to the commitments above, the ECE Capstone commits to allocating one of its 0.25 GTAs, assuming the course has at least 1.0 TA assignment, to serve as an "at large" resource for the Alliance as a whole, if EECS provides at least one TA with professional industrial experience developing of IoT systems. This means that this "at large" TA will hold office hours every week that any IOTA members' students may attend, and this TA will make his or her contact information and availability known to the IOTA Community Coordinator for publication on the IOTA website. In addition, time permitting, this TA will invest time and effort in helping to create shareable resources that the IOTA Community coordinator can also publish.
Furthermore, the ECE Capstone is willing to share meeting space (DB211) for short events or 24-hour use, which includes testing tools, to other members of IOTA and/or student groups associated with those members. To request permission for using this space, other member representatives must contact the "at large" TA, who may impose constraints on when and how the space and tools may be used, and/or may require that visitors only use the space when this TA is present.
The ECE Capstone will grant its Capstone students credit for some assignments associated with professional development if students participate in events organized by IOTA members. (Students will also have other options for fulfilling this professional development assignment.) These events may include domain-specific events organized by the ECE domain-specific TAs, or they may include events organized by other IOTA members (such as those held by the ECE Capstone domain-specific TAs, or the Alliance's member clubs). Students' credit will be based on participation metrics provided by the IOTA Community Coordinator (Section 2.1), which will take into account students' professional development, technical performance, presentations, collaboration, and project management.
The ECE Capstone is open to providing a small amount of funding to other members of IOTA for purchasing materials and supplies for events. Member representatives should contact the ECE Capstone representative for details.
ECE capstone will also provide limited faculty time to assist the alliance in forming and adapting to the needs of the alliance members.
Section 2.3.2: Specific CS On-campus Capstone Commitments
Kevin McGrath (firstname.lastname@example.org) represents the CS On-campus Capstone.
Although the CS On-Campus Capstone will not be making any TAs generally available "at large" to IOTA, the CS On-Campus Capstone will organize student teams into domains as noted above, and the TA assigned to each domain will organize optional events open to all members of IOTA.
In addition, other members of IOTA may contact the representative (Kevin McGrath) of this Capstone, on behalf of students, to request the use of hardware resources that this Capstone owns.
Section 2.4: The Master's in Software Innovation (MSSWI) Track
Chris Scaffidi (email@example.com) represents the MSSWI Track and has committed to oversee the IOTA Community Coordinator supplied by EECS (Section 2.1).
Students in this track generally participate in two graduate courses (CS 561: Software Engineering Methods, and CS 562: Software Project Management) as well as the graduate reading and conference seminar (CS 505). The two CS 56x courses include significant team-oriented project implementation (similar to the undergraduate capstones, but at a higher level), while the reading and conference seminar involves studying a technology and teaching it to other students.
When the MSSWI Track representative teaches CS 561 and 562, students in those courses may receive extra credit for participating in events held by IOTA members. These metrics will take into account the extent to which these graduate students participate in events in ways that promote skills development by less experienced students (such as undergraduates). The details of these metrics are as-yet to be determined.
If EECS provides CS 561 and 562 with one or more 0.49 TA with professional industry experience in engineering IoT systems, then that TA will be directed to spend time creating resources that students can use for creating such systems. Furthermore, the TA will work with the IOTA Community Coordinator to identify what resources would be useful to create and will make the resulting resources available to the Community Coordinator for sharing with other members of the Alliance.
In addition, students of CS 561 and 562 may contribute additional resources to the IOTA repository, in exchange for extra credit in CS 561 and 562. The details of what they will deliver, and for how much extra credit, remain to be determined.
Finally, if graduate students in the MSSWI Track ask to do so, then they may receive credit in CS 505 for teaching high-quality seminars on how to engineer IoT systems. The MSSWI Track representative will grade the graduate students who give these seminars. These seminars will be planned with the input of other IOTA member representatives, will be advertised via the IOTA Community Coordinator via the Alliance's website, and will result in new resources that the Alliance can share and reuse.
Section 2.5: The CS Network Security Course
Mike Rosulek (firstname.lastname@example.org) represents the CS Network Security Course.
This course will include at least one assignment that students can satisfy by participating in one or more events held by IOTA members (details to be determined.) In addition, if EECS assigns a TA with relevant professional experience to the CS Network Security Course, then that TA will be asked to author some short resources (such as a “How-To” document or two) related to securing IoT systems.
Section 2.6: The CS Undergraduate Operating Systems Courses
Ben Brewster (email@example.com) represents the CS Undergraduate Operating Systems Courses, including both the online and on-campus variants.
These courses will include at least one assignment and/or extra credit for participating in events conducted by members of the Alliance, when events are available to students in the Post-Baccalaureate or on-campus program and are made available to the class as a whole. In recognition of the desirability of fostering students' creation of personal projects, credit will be granted on the basis of metrics tracked by the Community Coordinator, with an emphasis on how students' portfolios grow as a result of involvement in Alliance members' events.
Section 2.7: The OSU Robotics Club
Matt Shuman (firstname.lastname@example.org) represents the OSU Robotics Club.
This is the largest club on campus, and it has a well-established history and reputation as well as a mission that extends far beyond IoT. To the extent that IoT overlaps with engineering of robotics systems, the Robotics Club will support the IoT alliance.
Specifically, the club will provide the Community Coordinator (Section 2.1) with access to initial knowledge-base content that can serve as a starting point for the online repository of training materials. Drawing upon its large membership base and industry connections, it will help to publicize events of mutual interest to the club and the alliance, both inside the university and outward toward companies. Finally, when Club events are open to students of other alliance members, the Club will provide the Community Coordinator with data on which students participate in these events (Section 2.1).
Section 2.8: The Hackathon Club
Temporarily Removed - additional permission still necessary from Hackathon Club.
Section 2.9: The Security Club
Mike Rosulek (email@example.com) represents the Security Club.
The Club will host one or more seminar per year where students can learn about security-related aspects of engineering IoT systems. The Club will provide the Community Coordinator with data on which students participate in these events, so that the Community Coordinator can track student metrics (Section 2.1).
Section 2.10: Inventors Enterprise
Donald Heer (firstname.lastname@example.org) represents Inventors Enterprise.
The Club will host one or more seminars per year where students can learn about entrepreneurship and hardware-related aspects of engineering with IoT systems. The Club will provide the Community Coordinator with data on which students participate in these events, so that the Community Coordinator can track student metrics (Section 2.1). Hardware will be loaned out by the club for purposes of the seminar as well as to other IOTA members. This will come from the inventory of the club with management and availability determined by the club’s resources and time.